16P — Jeu de Rôle en Interface Texte
Par admin le mercredi, mai 11 2016, 12:00 - 2015-2016 - Lien permanent
Ce projet a été réalisé par Julien Sahli.
Prenez part à une aventure épique dans un univers heroic fantasy !
1. Introduction
Depuis des années, je m'intéresse au jeu de rôle, et plus particulièrement au jeu de rôle sur table. Pour faire simple, c'est une réunion entre amis au cours de laquelle chacun incarne un personnage fictif, et évolue dans une histoire qui dépend de leurs actions et qui est racontée par le "maître de jeu", ou MJ. Dans la majorité des cas, celui-ci se réfère à des règles de jeu établies au préalable. J'ai moi-même testé différents jeux avec leur background et leurs règles respectives et j'ai été pris d'envie de développer mon propre jeu. L'étape d'après fut de programmer un site web qui permettrait à quiconque d'en profiter. L'aspect humain, convivial et flexible du jeu original est certes impossible à obtenir avec une interface numérique (ou du moins à mon niveau), mais on ne peut pas tout avoir :) . Par ici la visite du site en question !
Important : Avant de lire ce billet, je tiens à préciser qu'à l'heure où je le publie, je n'ai pas encore pu réaliser certains aspects du jeu que je mentionne, mais j'ai l'intention de les ajouter aussi vite que possible ! Ce billet décrit donc non seulement le travail que j'ai déjà effectué, mais également toutes les idées que j'ai eues pour l'améliorer mais que je n'ai pas encore pu incorporer, faute de temps.
2. Matériel et méthodes
Pour commencer, je considère qu'en lisant ces lignes, vous savez vous débrouiller avec le html, le css, le php et le sql. Si ce n'est pas le cas, je ne peux que vous recommander ce tutoriel pour le html et le css, et celui-là pour le php. J'expliquerai cependant certains détails techniques afin d'être sûr de me faire comprendre.
Tout d'abord, le code source de mon site est disponible ici.
Ce projet ne requiert dans son stade actuel comme matériel qu'un ordinateur disposant d'un moyen d'héberger des pages en php.
Je ne parlerai pas beaucoup du css dans ce billet, car il s'agit surtout à mon avis de connaître des mots-clefs et de les appliquer pour embellir la page selon son goût.
À ce propos : à l'heure où j'écris ces lignes, mon site a pour image de fond et pour favicon (l'icône qui apparaît dans l'onglet de la page) des images qui ne m'appartiennent pas. Je les ai incluses uniquement pour apprendre à le faire, mais dès que ce site sortira du cadre gymnasial, je changerai ces fonds d'écran par des images libres de droit ou dont je serai le propriétaire. Le changement ne sera toutefois pas visible sur le site dont j'ai donné le lien car je serai dans l'impossibilité de le modifier, et de même les ajouts futurs mentionnés ici ne seront pas visibles. J'effectuerai une copie du site que je modifierai, mais celui-ci sera à une adresse différente, que je mentionnerai, probablement dans les commentaires de ce billet de blog. Actuellement, deux images sont de moi : il s'agit des images mage.png et guerrier.png .
2.1 Identité du personnage
Lorsque le joueur commence une partie, il choisit un personnage parmi plusieurs archétypes de l'univers heroic fantasy. Pour l'instant les classes disponibles sont Guerrier, Mage, Voleur, et Prêtre. Chacun de ces personnages va être défini par plusieurs variables :
- Les caractéristiques
- L'équipement (à venir)
- Les objets (à venir)
- Les capacités de combat (à venir)
- Les variables de quêtes
Chaque variable va être stockée dans les variables de session. Pour l'instant, ces variables ne sont pas triées, mais dès que possible je les rangerai dans un array correspondant, respectivement stat, stuff, item, quest. Je pense utiliser pour cela un logiciel comme TexRep.
2.1.1 Caractéristiques
Les variables de caractéristiques sont en quelque sorte l'identité du personnage. Il y a pour l'instant 6 caractéristiques fondamentales : Force, Adresse, Volonté, Intelligence, Endurance, Esquive, ainsi que les points de vie et les points de mana. Il y a aussi la classe du personnage, son niveau et ses points d'expérience. Plus tard, j'implémenterai également une caractéristique de Charisme, et de statut.
Les caractéristiques fondamentales représentent les atouts et les points faibles du personnage. Un personnage fort pourra par exemple défoncer une porte plus facilement qu'un autre. Chaque point dans une caractéristique augmente de 2% les chances de réussite dans une action associée, (CF section 2.4.1 Interface d'épreuve) et augmente la puissance en combat (CF section 2.2.4 Interface de combat). Le Charisme, une fois implémenté, débloquera des répliques plus persuasives dans les dialogues (CF section 2.4.2 Interface de dialogue), permettra de marchander (CF section 2.4.3 Interface de transaction), et pourra potentiellement galvaniser les alliés lors des combats.
Les points de vie représentent la santé du personnage: s'ils tombent à 0, celui-ci meurt. Les points de mana représentent la capacité du personnage à lancer des sorts et à utiliser des capacités de combat (CF section 2.4.4 Interface de combat). Les points de vie et de mana (abrégés PV et PM) sont toujours compris entre 0 et 100, contrairement aux caractéristiques fondamentales qui peuvent progresser indéfiniment. Le statut, une fois implémenté, sera une variable qui décrira la santé du personnage de manière plus subtile que les points de vie, par exemple s'il a un membre cassé, s'il est malade, s'il est affamé, etc, et quelles incidences cela a sur ses caractéristiques fondamentales.
La classe du personnage correspond à l'archétype choisi en début de partie. Elle détermine notamment, en plus des caractéristiques fondamentales, les capacités de combat que celui-ci peut avoir. L'expérience est une variable allant aussi de 0 à 100. Le personnage doit en capitaliser le plus grand montant possible, car dès qu'il en acquiert 100, il gagne un niveau et toutes ses caractéristiques fondamentales augmentent d'un point.
Les caractéristiques du joueur sont définies à la création du personnage, les fichiers correspondants sont dans le dossier "classe".
Au début du jeu, une autre variable est déclarée : la difficulté. Elle rend plus ou moins facile les épreuves, et influera aussi sur la puissance des ennemis, une fois l'interface de combat implémentée. Pour que le joueur puisse la sélectionner, on fait appel à un simple formulaire.
2.1.2 Équipement
L'équipement sera, lorsque je l'aurai implémenté, un ensemble d'objets que le personnage transporte pour augmenter de manière passive ses caractéristiques. Ceux-ci seront répartis en différents types, et le joueur ne pourra en avoir qu'un seul de chaque type à la fois. (Par exemple, il ne pourra pas porter deux casques en même temps !) Une page avec un formulaire y est sera dédiée, pour que le joueur puisse choisir la manière dont il veut s'équiper. Il y aura 5 emplacements d'équipement : tête, torse, jambes pour les armures, ainsi que main droite et main gauche pour les armes et les boucliers, et éventuellement des emplacement secondaires comme pour une amulette ou un anneau magique. Tous les équipements disponibles seront stockés dans un fichier ou une base de données, et les variables d'équipement contiendront un nombre indiquant la quantité que le joueur possède
2.1.3 Objets
Les objets autres que les équipements que le personnage peut ramasser pourront être, une fois implémentés, de trois types : Utilisable (L'objet peut être utilisé à tout moment, par exemple une potion de soin pour regagner de la vie), Situationnel (L'objet ne peut êtres utilisé que dans certains cas et le personnage y est invité, par exemple une clef), Passif (L'objet n'a aucun effet en soi, mais peut tout de même être vendu). Chacun de ces types d'objets ont leur propre array à l'intérieur de l'array "item". Tous les objets disponibles sont stockés dans un fichier ou une base de données, et les variables d'objets contiennent un nombre indiquant la quantité que le joueur possède
2.1.4 Capacités de combat
Une fois implémentées, les capacités de combat seront, comme leur nom l'indique, des aptitudes que le joueur pourra utiliser en combat. (CF section 2.2.4 Interface de combat) Toutes les capacités de combat disponibles seront stockées dans un fichier ou une base de données, et les variables de capacité contiendront 1 si le joueur dispose de la capacité, ou 0 s'il ne la maîtrise pas.
2.1.5 Variables de quêtes
Les variables de quêtes enregistrent si le joueur a effectué une action qui lui permettra d'en effectuer une autre plus tard. (Par exemple avoir parlé à un pnj (personnage non joueur) pour apprendre une information cruciale qui lui permettra d'en persuader un autre.) Cela regroupe également les objets de quête, qui sont somme toute assez similaires dans leur fonctionnement aux objets situationnels, mais qu'il faut cependant distinguer car la possession d'un objet de quête est enregistrée dans la variable de quête correspondante, et pas dans une variable d'objet supplémentaire, qui serait superflue. De manière générale, une quête a plusieurs étapes à effectuer dans l'ordre, et les variables de quêtes renferment un nombre relatif à l'étape en cours. Par exemple, la page lieu/maison_brulee.php fait référence à la variable $_SESSION["mainquest"] Si celle-ci vaut 1, la page donne un objet au joueur et fait passer la variable à 2, pour qu'une autre page la fasse à son tour passer à 3, etc...
Les variables de quêtes sont donc extrêmement importantes en le sens qu'elles permettent à l'univers de s'adapter aux actions du personnage. Il est bien entendu possible qu'une quête ait différentes manières d'être accomplie, et donc différentes issues possibles. Pour gérer cela facilement j'envisage de coder prochainement cela ainsi : une quête qui n'est pas commencée n'amène pas de variable, une quête entrain de se dérouler est exprimée par une variable contenant une lettre et un nombre, la lettre désignant la manière dont le joueur a choisi d'accomplir la quête et le nombre l'étape de déroulement de celle-ci. Ce n'est cependant pas encore le cas.
Nous avons fait le tour des différentes variables définissant le personnage. Maintenant, abordons la question du monde.
2.2 Page principale
La majeure partie de l'aventure se déroule sur une seule et même page : main.php . Grâce au php, cette page change à chaque rechargement, selon les actions du joueur. Elle est composée d'uniquement 5 lignes de code :
<?php include "structure/header.php"; ?>
<?php include "structure/fonction.php"; ?>%%
<?php include "menu/menu.php"; ?>
<?php include "lieu/".$_SESSION["lieu"].".php"; ?>
<?php include "structure/routine.php"; ?>
<?php include "structure/footer.php"; ?>
La première question qui se pose est : que veut dire "include" ? Il s'agit d'une fonction qui sert à concaténer à un endroit précis du fichier courant le contenu d'un autre fichier. Voyons une par une chacune des pages qui sont appelées.
2.2.1 "structure/header.php"
Cette ligne inclut le fichier contenant la balise <header> au début du document, rien de bien compliqué, et si cela ne vous dit rien je doute que vous ayez pu comprendre le début de ce billet, alors allez voir par ici ! Ensuite, elle comporte 2 petits scripts : le premier stocke durablement le lieu du personnage (cela est utile notamment s'il va dans une page du menu, qui est hors de main.php) et la deuxième empêche le reste de la page de s'afficher si le personnage est mort. On pourrait penser que ces deux scripts devraient être dans la page structure/routine.php mais ils doivent être exécutés au début pour être efficaces. Par exemple, si le personnage est mort mais que la page s'affiche tout de même, il peut continuer à agir comme s'il était vivant, ce qui pose un petit problème étant donné que ce n'est pas un zombie. (Du moins pas pour cette version du site, mais qui sait ?)
2.2.2 "structure/fonction.php"
Cette ligne inclut des fonctions personnalisées (pour l'instant une seule) qui sont réutilisées plus loin. Cela permet de ne l'écrire qu'une seule et unique fois et de l'appeler à maintes reprises. Pour plus de détails sur la fonction qui y est présente, je vous invite à vous rendre à la section 2.4.1 Interface d'épreuve.
2.2.3 "menu/menu.php"
La ligne avec menu.php inclut un petit menu de jeu, qui s'écrit avec la balise <nav>. Ce menu permet au joueur d'accéder à d'autres pages que des lieux, notamment son inventaire, son statut... c'est ici que le script présent dans header.php qui stocke la variable $_GET["lieu"]dans $_SESSION["lieu"] prend toute son utilité : car en chargeant une des pages susmentionnées, la variable GET n'est plus gardée en mémoire. Les pages accessibles avec le menu sont très simples : elles ne font que renvoyer la valeur de certaines variables (le niveau ou l'expérience par exemple). Je projette d'ajouter un formulaire dans la page objet pour que le joueur puisse changer d'équipement. C'est tout pour cette section.
2.2.4 "lieu/".$_SESSION["lieu"].".php"
Pour mener à bien ce projet, il m'a en tout premier lieu fallu imaginer un moyen de transformer un récit en lignes de code. Un des aspects essentiels du jeu de rôle est de pouvoir faire se déplacer son personnage d'un endroit à l'autre. Imaginez un instant l'histoire d'une personne qui resterait exactement au même endroit pendant toute sa vie... difficile de rendre cela intéressant, n'est-ce pas? (Quoique, on pourrait imaginer un immense dialogue dans un style de jeu "enquête", mais ce n'est pas mon but ici). Mon idée pour gérer les déplacements serait de prendre une carte du lieu où se déroule l'aventure, marquer touts les endroits intéressants et les relier afin de former un réseau, auquel chaque lieu correspondrait à une page web sur laquelle figureraient des liens pour aller sur les lieux directement connectés. J'ai donc dessiné une telle carte. L'étape suivante est de réaliser des pages web pour tous ces lieux : il s'agit de celles évoquées plus haut. Toutes ces pages sont contenues dans le dossier "lieu".
La ligne incluant "lieu/".+$_SESSION["lieu"].".php" est celle qui permet à la page de faire naviguer le joueur entre les lieux. Pour comprendre son fonctionnement, il faut savoir que la variable $_GET["lieu"] contient le lieu dans lequel le joueur se trouve (logique, non?). Pour rappel, elle s'exprime dans l'URL, sous la forme nom_de_la_page?lieu=valeur. Chaque bloc de texte appelé avec cet include contient, en principe, un lien vers la page courante, mais avec une autre valeur pour la variable de lieu. Cela permet donc de recharger la page, en changeant la variable de lieu. Pour rappel, les points ( . ) disposés entre "lieu/" et ".php" sont les opérateurs de concaténation en php, ils permettent de fusionner les trois parties de l'expression.
2.2.5 "structure/routine.php"
La ligne avec structure/routine effectue quelques routines au chargement de la page. Pour l'instant, il y en a deux. Toutes deux sont très simples et fonctionnent avec un if. La première contrôle si le joueur a 100 points d'expériences ou plus, le cas échéant il gagne un niveau et perd 100 points d'expérience. La deuxième contrôle si le joueur 0 PV ou moins, et le cas échéant le déclare mort.
2.4 Interfaces
Dans cette section, je vais parler de ce que je désigne sous le nom d' "interface". Dans mon projet, une interface est un ensemble de lignes de code relativement complexe permettant à l'utilisateur d'interagir avec le monde, et dont la structure de lignes est récurrente. De ce fait, il est possible de créer des fonctions php générant automatiquement ces interfaces avec certains paramètres, et d'appeler ces fonctions au besoin.
2.4.1 Interface d'épreuve
Certaines action sont très faciles à effectuer (ramasser un objet par terre, etc), d'autres sont relativement compliquées (crocheter une serrure...) et il n'est pas acquis qu'elles réussissent automatiquement. Il faut donc déterminer si l'action est réussie ou non. Dans le jeu de rôle classique, une manière de procéder est de lancer un dé (selon les cas, à 6, 20 voire 100 faces). Si le résultat est inférieur ou égal à la caractéristique, le plus souvent majorée par un bonus ou un malus selon la difficulté de l'épreuve, le test est réussi. Cela a l'avantage d'être rapide à calculer, mais a aussi un inconvénient. Prenons l'exemple d'une épreuve au dé 20. Un joueur avec 6 dans la caractéristique concernée a 6 chances sur 20 de réussir le test, alors qu'un joueur qui a 14 a 14 chances sur 20 de réussir. Jusque là, rien d'anormal. Mais si ces deux joueurs venaient à gagner un points dans cette caractéristique, le taux de réussite du premier augmenterait de 7/6 alors que celui de l'autre joueur n'augmenterait que de 15/14. Par conséquent, plus une caractéristique est haute, plus celle-ci progresse lentement, et à terme tous les personnages ont à peu près les mêmes chances de réussir une épreuve et ils n'ont plus vraiment de points forts ou de points faibles. Mais en utilisant l'informatique, on peut automatiser tous les calculs et donc augmenter leur complexité. J'ai décidé de faire appel à une fonction qui croît toujours de la même manière : j'ai nommé l'exponentielle. J'ai donc établi la règle suivante: chaque point de caractéristique supplémentaire augmentes les chances de succès de 2%. On part d'une chance de réussite de 2/3 (c'est une valeur arbitraire, que j'ai déterminé empiriquement à force de jouer pour que les épreuves soient "bien calibrées".). On a ajoute 2% pour chaque point de caractéristique du joueur dont on retranche un certain montant pour éviter une réussite quasi-automatique.
Passons maintenant à l'informatisation des épreuves. L'interface correspondant intervient de manière passive, elle est cachée aux yeux du joueur et seul le résultat en est visible. Si celui-ci entreprend une action difficile, il ne réussit pas à chaque coup. On fait alors appel à une épreuve. Pour cela, j'ai créé une fonction, qui se trouve dans structure/fonction:
function epreuve($stat, $difficulte_epreuve, $id){
if(isset ($_SESSION["epreuve_".$id]) == FALSE)
if)>rand(0, 101))
$_SESSION["epreuve_".$id] = "gagne";%%
else%%
$_SESSION["epreuve_".$id] = "perdu";
}
Dans la première ligne, nous déclarons que toutes les lignes suivantes (entre les acolades {}) seront regroupées dans une seule et même fonction nommée épreuve, et que celle-ci comporte 3 paramètres : à savoir la caractéristique testée, la difficulté de l'épreuve (le montant qui sera retiré à la caractéristique) et le nom que nous voulons que l'output prenne. Dans la deuxième ligne, nous vérifions que l'épreuve n'a pas déjà été effectuée, ceci pour éviter que le joueur recharge la page jusqu'à qu'il réussisse! Dans la troisième, nous calculons la valeur à atteindre, puis jetons virtuellement un dé 100 et comparons le résultat, qui est enregistré dans une variable. Les lignes suivantes déterminent l'output. La suite de la page est divisée en 2, et une seule de ses parties sera interprétée, en fonction de l'output. Pour faire appel à cette fonction, il faut tout simplement écrire "epreuve()" suivi de ses paramètres à l'intérieur d'une balise php, en ayant pris soin d'inclure structure/fonction en amont de la page. C'est tout pour cette interface, qui est somme toute très simple.
2.4.2 Interface de dialogue
Parfois, le joueur sera amené à dialoguer avec d'autres personnages. Il aura le choix à plusieurs répliques et devra en sélectionner une, qui lui en dévoilera d'autres, etc. Les dialogues sont donc arborescents. Comme le personnage reste dans la majeure partie des cas immobile, il paraît logique que celui-ci reste sur la même page. J'ai donc choisi d'utiliser encore une fois un include. Nous incluons donc un ensemble de pages de dialogue à l'intérieur d'une page de lieu qui est elle-même inclue dans main.php (ça sonne un peu "Inception" tout ça, non? :P ). Ces pages de dialogue sont toutes rangées dans le dossier dialogue (sans blague ?) et leur nom est composé d'un mot (généralement le nom de l'interlocuteur) suivi d'un nombre. Cette structure est donc on ne peut plus simple, un include et c'est tout bon. Passons à la suite!
2.4.3 Interface de transaction
Cette interface n'est encore qu'un projet. J'ai prévu de pouvoir permettre au joueur d'acheter des objets. Je n'ai pas encore réalisé cette interface, mais je pense procéder ainsi : on crée une page où le joueur peut acheter plusieurs objets. Pour chaque objet, un hyperlien est présent. Tous renvoient à la même page, mais ils amènent tous une variable GET différente. Cliquer sur le lien charge une page qui identifie l'objet en question, regarde son prix dans une base de données, éventuellement le réduit en fonction du charisme, et retire ce montant du capital d'or du joueur. Si celui-ci est trop pauvre, la transaction est annulée. Finalement, l'objet acheté est ajouté à l'inventaire du joueur. À la fin de la transaction, une variable est modifiée, et si le joueur recharge la page, celle-ci détecte la variable et annule la transaction. J'ai d'ailleurs déjà utilisé ce système pour éviter des transactions supplémentaires et non sollicitées, par exemple sur la page lieu/orfevre_amulette.php où le joueur paye 40 pièces d'or pour faire avancer sa quête.
2.4.4 Interface de combat
Cette interface n'est encore qu'un projet. Si le joueur viendrait à se battre, une interface de combat s'ouvrirait. Il s'agirait d'un combat au tour par tour, où le joueur aurait le choix entre attaquer, utiliser un objet, utiliser une capacité de combat, ou fuir. Une attaque de base aurait 2/3 de chances de toucher, est ses dégâts seraient de 10+1D20 (Comprenez : 10 + le résultat d'un dé à 20 faces). Les caractéristiques auraient leur importance: la force augmenterait les dégâts physiques infligés (2% par point), l'adresse augmenterait les chances de toucher (2% par point), la volonté augmenterait la puissance des sorts (2% par point), l'intelligence augmenterait les chances de toucher avec un sort (2% par point), l'endurance diminuerait tous les dégâts reçus (2% par point) et l'esquive diminuerait les chances de se faire toucher (2% par point).
3. Résultats
La meilleure manière d'observer les résultats est, bien entendu, d'aller voir le site !
4. Discussion
Certains points sont à évoquer en ce qui concerne mon site.
Premièrement, toutes les pages contenues dans le dossier lieu ne sont pas forcément des lieux, mais plutôt des actions : par exemple la page orfevre_amulette.php ne décrit pas un lieu, mais une transaction. J'ai procédé ainsi car je n'ai pas eu le temps de mettre au point l'interface de transaction évoquée au point 2.4.3 mais que cette étape était essentielle au déroulement d'une quête.
Deuxièmement, le site comporte un défaut que je n'ai pas eu le temps de fixer pour l'instant : le lieu dans lequel se trouve le personnage est indiqué dans l'URL, et l'utilisateur peut sans autre le changer. (Tiens, et si je mettais lieu=salle_du_tresor ?). Cela devrait pouvoir être fixé en conservant le lieu précédent et en le comparant avec le lieu actuel. Une base de données devrait sûrement faire l'affaire. En allant plus loin, il serait également possible d'automatiser la génération des liens sur les pages en fonction de la base de donnée pour être encore plus efficient !
Finalement, et c'est sûrement le plus grand défaut que le site a actuellement, c'est que celui-ci ne dispose pas de système de sauvegarde. Toutes les informations sont stockées dans des variables de session, qui eh bien durent le temps de la session, ce qui n'est hélas pas éternel. Pour pailler à ce problème, j'envisage d'implémenter une base de données au site, qui stockerait ces informations de manière plus pérenne. Je donnerait au joueur la possibilité de se créer un compte, et une fois connecté il disposerait d'un lien pour sauvegarder toutes ses variables de session dans une base de données et ce faisant il pourrait les charger plus tard. Il est tout à fait envisageable de lui fournir plusieurs emplacements de sauvegarde, pour jouer plusieurs classes différentes par exemple. Je pense résoudre ce problème avec MySQL et phpMyAdmin.
5. Conclusion
Le site dans son état actuel est loin d'être achevé, et on ne peut pas vraiment dire qu'on passera des heures dessus et qu'on y deviendra accro. Cela vient du fait que je n'ai simplement pas eu assez de temps pour rendre la chose vraiment intéressante. Cependant, presque tous les mécanismes de jeu sont déjà là, et je sais déjà comment réaliser ceux qui manquent. Je pourrais peut-être même passer à l'étape d'après, à savoir développer un programme qui écrirait le site à ma place, ce qui me ferait gagner énormémemt de temps, et pouquoi pas servir à d'autres personnes qui voudraient elles aussi créer leure propre aventure mais qui ne maîtrisent pas le raffinement extrême qu'est la programmation (et j'exagère à peine) !
Avant d'avoir écrit ce site, j'avais très peu d'expérience en php. Le fait d'avoir commencé à l'écrire m'a permis de me familiariser beaucoup plus avec ce langage, et à présent je n'irai pas jusqu'à dire que je le maîtrise totalement, mais je pense le connaître suffisamment pour réaliser beaucoup de choses avec lui, ou du moins avoir une idée de comment s'attaquer à un problème en php. Ce site m'a donc permis d'apprendre beaucoup de choses qui touchent au php, et qui peut-être s'appliquent aussi à d'autres langages. Je dispose maintenant de tout ce qu'il me faut pour améliorer le site jusqu'à le rendre très intéressant, et si vous êtes toujours entrain de lire ce billet et que vous débutez, je ne peut que vous encourager à prendre vous aussi votre clavier et commencer à coder ce qui vous passe par la tête !