Tout développeur le sait : il est parfois difficile d'avancer dans ses lectures lorsque l'on cherche à apprendre de nouvelles notions, d'autant qu'il est même parfois difficile de bien choisir la ressource qui traite de ces notions. De plus, nous n'avons, pendant la lecture, que notre point de vue et celui de l'auteur (ou du moins ce que l'on en comprend) pour juger de la pertinence des informations que l'on lit.
C'est pourquoi des membres de la communauté proposent de se réunir à intervalles réguliers pour discuter à propos d'un livre, sur le discord https://discordapp.com/invite/zcWp9sC , en vocal.
Les objectifs sont les suivants :
avoir un groupe pour se motiver mutuellement à continuer la lecture ;
avoir des points de vue différents, d'autres habitudes, d'autres langages ;
produire des commentaires pertinents à propos de diverses ressources.
Pour rester ouvert à un maximum de personnes différentes (autant d'un point de vue du langage que du niveau), le livre choisi devra :
parler d'un thème de l'informatique au sens large (y compris conception, gestion de projet, etc), indépendant d'un langage (même si l'illustration par un langage particulier convient) ;
posséder un intérêt pour des développeurs de tout niveau (le but est d'avoir matière à débattre y compris pour des débutants, pas de faire du question-réponse) ;
être dispo quelque part en PDF.
Le livre en question sera choisi (par la communauté) en deux temps, d'abord diverses propositions seront faites, puis votées. Un post de forum sera préparé pour cela.
Actuellement, nous pensons que ça serait une bonne idée de se rassembler une fois par semaine pendant 30 minutes à 1h (cela pourra bien entendu être adapté selon comment se passent les séances), pour avoir un maximum de personnes, tout en gardant un débat avec suffisamment de contenu pour que cela en vaille la peine. Un autre post de forum sera créé pour choisir le prochain créneau. Cela n'interdit pas, bien entendu, de continuer les discussions en dehors de ces créneaux.
Comme dit précédemment, ces discussions auront lieu en vocal sur un salon du Discord d'OC. Il est possible de venir en simple spectateur (pour écouter), si l'on souhaite participer, nous demandons d'être sûr à l'avance de la qualité de son micro.
Une séance traitera a priori d'un chapitre du livre. Pour une séance, trois intervenants seront choisis, parmi les volontaires, pour (dans l'ordre) :
faire un résumé des séances précédentes (s'il y a lieu),
présenter les thèmes et questions à aborder pendant la séance,
prendre des notes sur ce qui est dit pendant la discussion.
Cela implique notamment que les questions et thèmes de discussions devraient être transmises à l'avance à la personne chargée de les présenter.
En fin de séance, les notes prises pourraient être relues rapidement pour s'assurer que rien d'incohérent n'a été introduit. Et elles serviraient pour préparer le résumé lors de la séance suivante et produire le résumé global du livre qui sera accessible par la suite sur le post de forum correspondant à ce livre.
Si un chapitre semble trop long pour une séance, il pourrait être coupé en deux à l'avance. De la même manière, si l'on s'aperçoit qu'à la fin d'une séance, il y a encore matière à débattre, le chapitre suivant pourrait être décalé d'une semaine.
Voilà, si vous êtes intéressés, surveillez bien les forums en attente de la première annonce de livre. Tout cela a déjà été bien discuté sur le discord (channel #club-de-lecture) mais les modifications du format ne sont bien entendu pas fermées à la discussion.
L'étape suivante pour le club de lecture est de choisir un livre. Ce livre va être choisi par la communauté, en respectant les contraintes indiquées lors de l'annonce.
Pour cela, je vous invite à proposer des livres dans cette discussion ou sur le discord de la communauté : https://discordapp.com/invite/zcWp9sC (dans le canal `club-de-lecture`).
Dans une semaine, un vote sera lancée et vous pourrez choisir le livre que vous souhaitez.
De plus, il faut choisir la date et heure de la semaine pour le club de lecture. Le vote pour cela se passe à l'adresse suivante : https://framadate.org/9PazGmJzs4uSSXXK
Pour le moment, peu de propositions de livres ont été fait. Pour éviter de prendre trop de temps sur le choix du livre, celui qui avait été proposé sur le Discord : Coder proprement, de Robert C. Martin. Pour ceux qui n'ont pas ce livre, n’hésitez pas a demander sur le Discord si quelqu'un a le PDF du livre.
Pour l'heure du club de lecture, pour le moment, le sondage penche pour 19h-20h, en début de semaine. N’hésitez pas a donner votre avis sur le sondage. Celui-ci sera ouvert jusqu’à la fin du mois.
Dernière ligne droite. Les votes sont clos, le rendez-vous hebdomadaire pour le club de lecture sera tous les lundi, de 20 heure a 21 heure. Le livre sera "Coder proprement", de Robert C. Martin.
Pour ceux qui veulent discuter en vocal avant de commencer le club de lecture, en particulier pour tester vos micros, rendez-vous lundi prochain a 20h, sur le discord.
Le club de lecture commencera la semaine suivante (le lundi 16 a 20h), par la discussion sur le premier chapitre.
Si vous souhaitez tester vos micros, discuter du club de lecture ou simplement dire bonjour, on est connecté sur le vocal du discord ce soir jusqu'à 21h.
Petit rappel, la première séance du club de lecture à lieu ce soir à 20h (heure française), sur le discord https://discordapp.com/invite/zcWp9sC. Nous discuterons du premier chapitre, "Code propre", du livre "Coder proprement", de Robert C. Martin.
Merci à tous les participants hier, nous étions nombreux et la discussion fut intéressante.
Suite a des problemes techniques (facon polie de dire que j'ai fait du n'importe quoi), la discussion n'a pas pu être enregistrée. On verra pour corriger cela la prochaine fois.
Voici le résumé de la discussion, écrit par Ksass`Peuk. (Merci à lui)
Séance du 16 octobre. Chapitre 1
"Coder Proprement" est un livre de Robert C. Martin, dît "Oncle Bob". Il est principalement connu pour ses contributions à propos de la méthode Agile, de la gestion de projet et des principes SOLID. Ses autres livres sont également intéressants, il ne faut pas hésiter à les lire aussi.
Les objectifs généraux de ce livre sont de fournir :
des guidelines pour la rédaction de code: noms, fonctions, commentaires, mise en forme,
une certaine connaissance des structures de données,
la bonne pratique qu'est "tester" le coder.
Avec pour finalité d'être capable :
de différencier le bon et le mauvais code,
d'écrire du bon code,
de transformer du mauvaise code en bon code.
Chapitre 1
Le but de ce chapitre est de commencer à répondre à la question "qu'est ce qu'un code propre ?", à travers trois questions générales:
pourquoi aura-t-on toujours besoin de code ?
que le coût du désordre ?
qu'est-ce qui caractérise un code propre ?
Il y aura toujours du code :
L'abstraction augmente et l'on semble avoir de moins en moins besoin de coder, mais le code n'est finalement qu'un langage dans lequel on exprime nos exigences et il y aura toujours des exigences à exprimer.
Le coût du désordre :
Causes
Les raisons entraînant la création d'un mauvais code sont très souvent reliées à un problème plus général dans tout projet : la pression du temps. C'est généralement du code réalisé trop vite pour répondre le plus rapidement possible à un besoin sans tenir compte de la maintenance future, on remet "à plus tard" le fait de rendre le code propre, mais "plus tard" signifie "jamais".
Conséquences
Il s'en suit un ralentissement de la productivité à cause de d'un code négligé dans lequel il est difficile d'avancer, car il est difficile à comprendre et aucune modification n'est négligeable. Surtout que reprendre à 0 est généralement complètement impossible et mène simplement aux mêmes travers.
Produire du bon code est une question de survie professionnelle.
Fausses causes, attitude
Le relationnel avec les décideurs et les nouveaux développeurs est important. Les développeurs ont une trop forte tendance à rejeter la faute sur les décideurs qui les pressent mais il est de leur devoir :
de dire non lorsque quelque chose est impossible,
de s'assurer qu'il sera rare de devoir dire non à une demande faisable (avec un bon code).
Code propre :
Regroupement de plusieurs point de vue à propos de la rédaction de code. Un code propre doit être :
élégant : un code agréable à lire est plus facile à lire et donc plus facile à écrire.
simple : il y a une certaine idée de minimalisme (principe KISS), relié au point suivant ...
efficace : optimal en un certain sens, rien ne permet de l'améliorer de manière évidente,
explicite : il doit être assez expressif pour ne cacher aucune intention du développeur,
destiné à être partagé : fait pour être lu par des humains, et le désordre appelle le désordre.
testé : on assure qu'il fait ce que l'on veut (et les tests ré-expriment les besoins).
Règle du boyscout : le code doit être plus propre que quand on est arrivé. Nous sommes reponsables d'écrire du code propre, de le maintenir propre et au besoin de le nettoyer.
Questions abordées pendant les discussions :
Q1 : il parle d'un style d'écriture, de manière de concevoir.
Il faut que le code soit conçu pour être compréhensible, mais cela va plus loin que juste la bonne architecture et la bonne organisation. On revient sur l'expressivité : le code montre clairement l'intention du développer, il ne cache rien, il est limpide.
Q2 : bonnes pratiques dans les langages à travers des guidelines.
Les designs patterns sont un exemple dans le point sur la conception. Ils peuvent néanmoins aussi aider d'autres codeurs à comprendre ce qu'on a voulu exprimer parce que ce sont des schémas connus (sans être figés ! Il sont sujets à adaptation). Le principal second intérêt des DP est de comprendre comment on a abouti à leur conception.
L'utilisation des commentaires est un exemple sur le style d'écriture. Les commentaires ne doivent pas servir à comprendre l'intention du code. Ils doivent seulement aider à faire comprendre éventuellement des point des détails du code qui ne sont pas exprimables par le langage. Lorsqu'un code a besoin de commentaires expliquant le patch d'un patch, d'un patch, c'est le signe que l'on travaille sur un mauvais code.
Documenter est délié de la notion de commentaire. Ce n'est pas parce que le langage fournit la documentation par l'intermédiaire du commentaire (au sens du langage) que l'on est effectivement en face de commentaires.
Q3 : Relation avec les décideurs : de la difficulté à être entendu avec les décideurs.
C'est important d'avoir un bon relationnel et être capable :
d'expliquer à d'autres,
d'apprendre aux autres à gérer ces problématiques.
La méthode AGILE est une tentative de résolution par l'introduction du "business" au niveau de la production du code. Les dérives courantes sont l'utilisation de cette méthode pour reconstituer un modèle non agile où les développeurs exécutent sans se faire entendre.
Il est important de présenter de manière concrète des fonctionnalités auprès des décideurs mais surtout aux destinataires du projet. Idéalement les réunions business et fonctionnalités devraient être complètement séparées pour éviter ce type de dérive.
Addedum de discussion : l'UML (ou formalisme équivalent) n'est pas toujours adapté pour la compréhension mais peut aider pour le dialogue avec des non-initiés.
Q4 : Relation avec les apprenants : problème de formation des personnes.
Apprentissage : projet jetable, problème pour acquérir de la compétence sur la maintenance de projet.
Nécessité de formation personnalisées pour former les gens au plus près et ne pas les lâcher complètement dans la nature avec un faux sentiment de compréhension.
Problématique de l'enseignement "classique" vs les formations internet : impossible de créer et suivre des
projets sur le long terme. C'est possible sur les formation internet, mais pas souvent fait.
Autres questions non abordées :
Opposition entre code efficace vs premature optimisation
Certains experts cités dans ce premier chapitre indiquent que pour eux, un code propre est un code efficace.
L'idée est qu'un code qui est déjà optimal n'aura pas besoin d'être modifié et donc demandera moins de maintenance.
Est-ce que cette idée de code optimial ne s'oppose pas au problème de premature optimisation ?
Choix du langage de programmation
Deux approches sont possibles pour choisir le langage de programmation (mais on peut étendre cette question a tous les choix technologiques sur un projet) :
utiliser le langage le plus adapté à un problème. Donc potentiellement un langage que l'on ne maîtrise pas.
utiliser un langage que l'on maitrise, meme s'il n'est pas le plus adapté à un problème. (Dans la limite du raisonnable, on ne va pas créer un site web en assembleur).
Le club de lecture sera exceptionnellement repoussé au Lundi 30 Octobre, beaucoup trop d'absents à prévoir pour ce Lundi. On reste cependant sur le chapitre 2.
Et voici le résumé de la séance de la semaine dernière, sur le chapitre 2 "Noms significatifs". Merci a Ksass`Peuk pour ce résumé.
Chapitre 2
Le but de ce chapitre est d'établir un certain nombre de règles simples pour
avoir un bon nommage des différents éléments d'un programme (variables,
fonctions, classes, etc).
Les différents points abordés par ce chapitre sont :
noms révélateurs d'intentions
éviter la désinformation
faire des distinctions significatives
choisir des noms prononçables
choisir des noms compatibles avec une recherche
éviter la codification
éviter les associations mentales.
noms des méthodes
noms des classes
ne pas faire le malin
choisir un mot par concept
éviter les jeux de mots
choisir des noms dans le domaine de la solution
choisir des noms dans le domaine du problème.
ajouter un contexte significatif
ne pas ajouter de contexte inutile
Noms révélateurs d'intentions
Un bon nom doit exprimer, pour l'élément qu'il nomme :
la raison de son existence,
son rôle,
son utilisation.
Typiquement, s'il y a besoin d'un commentaire pour expliquer cela, le nom est
mauvais. Non seulement il est important de trouver un bon nom mais il faut
être prêt à changer quand on en trouve un meilleur.
Une nouvelle fois le point crucial est de révéler les intentions du code.
Le problème n'est généralement pas dans la trop importante simplicité du code
mais plutôt dans la quantité d'informations implicites qu'il renferme, cela
implique du lecteur la connaissance d'informations qui ne sont pas expliquées
par le code.
Exemples typiques :
signification de valeur numériques en dur dans le code,
signification d'un indice pour un tableau,
manière particulière d'utiliser une variable ou une fonction.
Éviter la désinformation
Le nom ne doit pas risquer de détourner le sens du code. Mieux vaut éviter,
par exemple d'utiliser un mot comme "liste" dans un nom si on ne désigne pas
précisément une liste (qui a un sens particulier en programmation).
Il faut également faire attention à ne pas utiliser des noms trop proches qui
peuvent induire en erreur car l'on ne remarque pas immédiatement les différences
qui peuvent apparaître.
Un bon nom implique que l'on n'a pas la nécessité d'aller voir les commentaires
avant d'auto-compléter un nom (et pas le besoin d'aller voir une liste de
fonctionnalités proposées par exemple).
Caractères prise de tête si mal utilisés:
"o" majuscule (facilement confondu avec zéro)
"L" minuscule (facilement condondu avec un)
Faire des distinctions significatives
Modifier un nom pour le compilateur, c'est aller aux devants de problèmes.
Exemple typique : renommage d'une variable "qui a le même sens" qu'une autre
pour éviter le conflit de nom. Si les variables ne sont pas les mêmes, elles
n'ont nécessairement pas le même sens.
Mauvaises pratiques :
introduction de faute volontaire dans un mot pour le différencier,
utilisation de numéros,
utilisation de mots parasites.
Généralement, on ne provoquera pas de désinformation mais au minimum, on
n'exprime pas clairement les intentions du code.
Le mots comme "info" ou "data" ne sont pas précis. Difficulté par exemple de
différencier correctement "MachinData" et "Machin", rendant difficile le fait
de savoir laquelle des deux on doit utiliser pour obtenir une information
particulière quand on utilise l'une ou l'autre.
Conseil : ne jamais mettre le mot variable dans le nom d'une variable, ou
array dans un tableau, ou string dans une chaîne, etc.
Choisir des noms prononçables
Besoin dû principalement au fait que notre cerveau est câblé pour mieux
manipuler des choses prononçable. Cela permet entre autre d'avoir une
conversation intelligible avec une autre personne.
Choisir des noms compatibles avec une recherche
Éviter par exemple les noms d'une seule lettre et ou les constantes numérique,
qui sont difficiles à rechercher dans un texte. Par ailleurs l'inversion de
chiffres dans une grande constante peut rendre cette constante impossible à
détecter.
La longueur d'un nom doit correspondre à la taille de sa portée.
Plus le nom est susceptible d'être recherché à plusieurs endroit, plus il doit
être facile à rechercher.
Éviter la codification
La codification doit être apprise, ce qui est une charge de travail inacceptable
quand on doit déjà se taper l'apprentissage de la base de code sur laquelle on
arrive. D'autant que les noms codifiés sont souvent imprononçables et sujets
aux erreurs de saisies.
Notation hongroise
Importante dans l'API C Windows, créée à un moment où la vérification de type
était pour ainsi dire inexistante, et que l'on avait besoin d'un mécanisme
explicite dans le nommage pour mémoriser les types.
Ce n'est plus le cas aujourd'hui, la plupart des langages étant fortement typés
ou inversement, certains langages rendant la distinction de type généralement
inutile.
Bref : la notation hongroise, aujourd'hui, ne sert plus à rien.
Préfixe des membres
Préfixage "m_" pour les membres inutile : les classes et fonctions doivent être
assez courtes pour qu'une telle disctinction soit inutile. Ce préfixe
représenterait alors un foullis inutile.
Interfaces et implémentations
Mieux vaut éviter de commencer une interface avec "I". Au choix, il est plus
pertinent de signaler une implémentation (par un suffixe "Imp" par exemple).
Eviter les associations mentales.
C'est le problème des noms qui sont insuffisamment explicites au sens où le
développeur doit faire lui même un effort pour réassocier le nom à un autre nom
plus explicite correspondant au concept réel.
Exemple : initiales de plusieurs mots que le développeur doit lui même réassocier
à ces mots pour finalement atteindre le concept.
Noms des classes
Nommer les classes par des groupe nominaux (pas de verbe).
Éviter les mots trop généraux comme : Manager, Processor, Data, Info, etc.
Noms des méthodes
Choisir des mots auquels on s'attend :
get pour recevoir de l'information,
is pour exprimer un prédicate,
etc.
Ne pas faire le malin
Éviter l'humour lorsque l'on nomme des éléments d'un programme. Si la blague est
oubliée, cela peut porter à confusion. Dites ce que vous pensez, et pensez ce que
vous dites.
Choisir un mot par concept
Et s'y tenir ! Typiquement éviter de faire cohabiter : fetch, retrieve et get.
Les noms doivent être autonomes et cohérent, si les concepts sont similaires,
les écritures de ces concepts doivent être simulaires, et inversement.
Cela constitue le lexique du programme et il ne doit pas perturber le lecteur.
Éviter les jeux de mots
Lorsqu'un mot peut avoir deux sens différents, mieux vaut le bannir. Par exemple
lorsque le concept est semblable mais agit de manière sensiblement différente,
mieux vaut choisir un autre mot.
Choisir des noms dans le domaine de la solution
Le domaine du problème n'est généralement pas le domaine des développeurs du
code. Mieux vaut choisir des mots qui sont dans le domaine de la solution (donc
typiquement des termes informatiques).
Choisir des noms dans le domaine du problème
Lorsque le concept n'appartient PAS au domaine informatique, ne pas essayer de
simplifier et vulgariser. Mieux vaut utiliser le terme technique exacte du
problème pour pouvoir faire appel à un expert du domaine le cas échéant.
Ajouter un contexte significatif
La plupart des noms ne sont pas significatifs en l'état. Il faut leur redonner
un contexte à travers des classes, fonctions ou espaces de noms appropriés. Voir
d'ajouter un préfixe en dernier ressort.
Ne pas ajouter de contexte inutile
Éviter de mettre de l'information redondante (le nom de l'application elle-même
par exemple) ou hors de propos (distinctions adresse postale d'un client ou d'un
fournisseur).
Mots de la fin
Le choix des noms est difficile et nécessite
une bonne aptitude à décrire,
une culture générale partagée,
un bon enseignement.
Beaucoup de développeurs ont peur du renommage, mais nous ne mémorisons
généralement pas réellement les noms dans un programmes. Nous les traitons et
les oublions quand nous avons fini de travailler sur une zone particulière du
programme.
Questions abordés pendant les discussion
Nous avons globalement eu moins de discussions pendant cette séance, le chapitre
énonçant finalement des usages qui sont déjà assez fortement présents chez les
développeurs pros.
Q1: Point de désaccord sur la présence de mots comme "list" dans un nom
Par exemple pour distinguer un élément d'une collection VS une collection
elle-même. D'un côté l'utilisation du pluriel peut parfois être dure à
remarquer. D'un autre côté, l'ajout d'autres mots "parasites" comme "group_of"
ou "bunch_of" conduit à de l'imprécision. Au cas par cas, cette règle peut
sembler un peu forte.
Q2: Choix des noms prononçables, portage de vieux code
Certains code dans des langages comme Cobol imposent des contraintes fortes
sur le nommage des variables qui ont souvent mené à des dérives comme des
noms composés quasi-exclusivement d'initales et de chiffres. Ces noms
imprononçables sont très généralement source de confusion, lors d'un portage
mieux vaut complètement renommer ces éléments.
Q3: Point sur la codification VS la création d'un lexique
Ne pas confondre l'utilisation d'un lexique commun et la codification. Si
l'importance du lexique devient telle que l'apprendre et le comprendre n'est
plus triviale alors ce lexique tire vers la codification ce qui est une
mauvaise chose.
Q3b: notation hongroise
Cette notation a en plus le défaut de ne pas être robuste à la maintenance,
si l'on change légèrement le typage des éléments, on peut se retrouver à
devoir changer le nom de la variable alors que son utilisation et son sens
n'ont pas changé.
Q4: Contexte de noms : les espaces de noms
Les espaces de noms sont très utiles pour organiser les éléments d'un
programme cependant tous les langages ne possèdent pas la même notion d'espace
de nom (pas le même contexte d'utilisation et pas le même impact sur le code),
et même la présence d'un tel mécanisme ne garantit pas que les développeurs
vont l'utiliser.
Pour comparaison, on peut prendre la notion d'espace de noms à la C++ et la
notion de package à la Java. Java y définit une notion de visibilité, ce qui
n'est pas le cas de C++, et malgré le fait que cette notion d'espace de nom
permettent de donner plus de sens au code (par la visibilité justement), cette
notion ne semble pas être si utilisée par la communauté Java.
N'oubliez pas ce soir, nous discuterons des chapitres 6 "Objets et structures de données" et 7 "Gestion des erreurs". Rendez-vous a 20h sur le vocal du discord.
Lors de la séance le lundi 12 février, nous avons discuté des points suivants :
les chapitres 14 à 16 sont trop spécifiques au Java et sont moins intéressants à discuter. Donc on ne les fait pas.
le chapitre 17 reprend tous les points abordés dans le livre. Nous avons fait une relecture rapide.
Ksass`Peuk s’est proposé pour faire un résumé du livre.
En conséquence, nous pouvons considérer que la lecture du livre "Coder proprement" de R.C. Martin est finie et nous pouvons passer au livre suivant. Plusieurs décisions ont été prises :
ne plus se limiter à un livre accessible aux débutants.
ne plus se limiter à un livre en français.
ne plus se limiter à un livre de petite taille.
Il a également été décidé de s’orienter vers un livre sur l’intelligence artificielle et/ou l’algorithmique. Les livres proposés au vote sont donc les suivants (sous confirmation que les PDF sont disponibles) :
Bien sûr, rien n’est figé dans le marbre, vous pouvez toujours discuter de ces points sur le discord. Le sondage sera créé dimanche soir sur le discord, vous avez donc quelques jours pour proposer d’autres livres et discuter des propositions.
Nous sommes en train de discuter pour développer les activités sur Twitch. En plus des propositions dont j’ai déjà, nous étudions la possibilité de créer des présentations avec discussions en live.
N’hésitez pas à participer aux discussions sur le discord.
Le livre actuel "Introduction to Algorithms" ne semble pas plaire a beaucoup de monde. Rendez vous demain, pour ceux qui veulent, pour discuter rapidement sur un éventuel changement de livre. A 20h, sur le discord (cf ma signature). On va choisir très probablement livre plus orienté débutant et en français.
Est-ce une erreur de vouloir apprendre à développer des jeux vidéos ?
La création de jeux vidéos est probablement la motivation principale de nombreux débutants en programmation, particulièrement en C++. Malheureusement, les raisons d'un tel engouement sont souvent basées sur des des a priori sur le développement de jeux vidéos.
Il faut reconnaître que le développement de jeux vidéos est un domaine qui peut être passionnant. En premier lieu parce que les jeux vidéos en eux-mêmes sont passionnants. Mais aussi parce que les jeux vidéos demandent des compétences dans de très nombreux domaines, artistiques ou techniques : graphismes, sons, game design, performances, intelligence artificielle, etc.
Le but de cette discussion va être d'avoir le point de vue général d'un développeur de jeux vidéos sur les différentes problématiques de ce domaine.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.