Comment créer un fichier package.json pour ses projets TypeScript ?

Le fichier package.json est un élément central de tout projet TypeScript ou JavaScript moderne. Ce fichier JSON, situé à la racine de votre projet, contiendra "toutes" les métadonnées de votre projet (nom, version, description, auteur, licence, …), les dépendances de votre projet (bibliothèques externes), et tous les scripts permettant d'automatiser des tâches, comme la compilation ou le démarrage de l’application. C'est pourquoi nous verrons comment créer le fichier package.json (manuellement ou avec un gestionnaire de paquets) en détail !

Nous en profiterons également pour voir ensemble à quoi sert un fichier package.json, ainsi que des exemples pratiques et des bonnes pratiques autour de ce fichier ! Enfin, je répondrais à la fin à quelques questions récurrentes au sujet du fichier package.json (différence entre dépendances et dev-dépendances, comment publier un package sur npm, et à quoi sert le fichier package-lock.json). Donc… tout un programme ! Alors prêt ? C'est parti !

Remarque : si vous souhaitez voir des exemples concrets de programmes TypeScript, n'hésitez pas à faire un saut dans la rubrique "Projets", où vous trouverez des exemples de codes TS (Mini Chat Bot, API REST Node/TS, …), avec leur fichier package.json correspondant ! Jetez-y un coup d'oeil, c'est toujours instructif !

Qu'est-ce que package.json, et comment le créer ?

Pour faire simple, je dirais que le fichier package.json est un fichier de description/configuration au format JSON, pour projets JavaScript/TypeScript, s'appuyant sur un gestionnaire de paquets du type npm, yarn, pnpm, ou autre. Vous serez donc amené à créer un fichier package.json dans vos projets NodeJS, React, Vue, Angular, et autres. Ce fichier permet en outre de caractériser un projet avec des métadonnées, détailler les dépendances requises, et définir des scripts de lancement.

Pour créer un fichier package.json, deux méthodes s’offrent à vous : soit le créer manuellement, soit utiliser un gestionnaire de paquets (comme npm, yarn, ou pnpm, par exemple). Je vous propose donc de voir ces 2 méthodes, à présent !

Créer un fichier package.json manuellement

Bon là, comme vous l'aurez compris, y'a rien de plus simple à faire ! Car il suffit de créer un fichier vierge à la racine de votre projet, nommé "package.json" ! Mais comme vous vous en doutez, il va falloir remplir ce fichier, pour qu'il serve à quelque chose 😉

Voici un exemple de contenu pour fichier package.json (version minimaliste pour l'instant, mais on va étoffer ensuite !) :

{
  "name": "mon-projet",
  "version": "1.0.0",
  "description": "Un projet TypeScript",
  "main": "index.js"
}

Et avouez qu'il n'y a rien de bien compliqué à comprendre, pour l'instant ! Car là, avec cet exemple de fichier package.json, on ne fait que donner un nom à son projet, un numéro de version projet, un descriptif projet, et enfin, un nom de fichier principal pour notre projet (en l'occurrence index.js ici, mais ça pourrait être un tout autre nom).

Voilà ! Votre fichier package.json est prêt à l'emploi, comme on dit ! Simple, non ? Pour autant, lorsqu'on débute, on ne procède quasiment jamais ainsi (de façon manuelle, j'entends). Car comme vous allez le voir juste après, il existe un moyen d'aller bien plus vite, et de manière plus encadrée, pour créer son fichier package.json ! Après, si vous maîtrisez tous ses champs et paramètres du fichier package.json, vous pourrez effectivement le créer et le configurer de manière manuelle.

Créer un fichier package.json avec npm, yarn, pnpm, bun, ou autre

Comme je vous l'ai indiqué précédemment, il existe un moyen simple de créer un fichier "package.json". Pour cela il suffit d'utiliser un gestionnaire de paquets, comme npm, yarn, pnpm, bun, ou autre, pour générer un fichier package.json (de manière semi/pleinement automatisée, qui plus est !). Cela se fait tout simplement via le terminal, en tapant la commande suivante :

1. "npm init" pour créer un fichier package.json personnalisé (ou taper yarn init si vous préférez yarn, pnpm init si vous préférez pnpm, bun init si vous préférez bun, etc)
2. ou "npm init -y" pour créer un fichier standard package.json, sans se poser de questions (ou taper yarn init -y si vous préférez yarn, pnpm init -y si vous préférez pnpm, bun init -y si vous préférez bun, etc)

La 1ère méthode vous permettra de créer et personnaliser votre fichier package.json, à l'aide du gestionnaire de paquets de votre choix (yarn, pnpm, npm, bun, …). Dans ce cas, vous serez amené à répondre à tout un tas de questions (nom du projet, version, description, etc), afin de pouvoir générer le fichier package.json souhaité.

La 2ème méthode vous permettra de gagner du temps, en créant un fichier de configuration package.json par défaut. C'est d'ailleurs la méthode privilégiée par tous ceux qui débutent en JS/TS, pour commencer à faire leurs premiers pas. Et je vous invite à faire ainsi, même si, ne vous leurrez pas, le fichier package.json est à terme quelque chose qu'il faut maîtriser, pour construire des projets solides, et pérennes.

Remarque : le gestionnaire de paquets le plus utilisé étant npm, j'utiliserais seulement npm pour la suite de cet article ; mais vous avez bien compris que vous êtes libre d'utiliser autre chose, comme yarn, bun, pnpm, etc !

Pour info, voici les questions posées par le gestionnaire de paquets "npm", lorsqu'on exécute la commande npm init :

À quoi sert un fichier package.json ?

Pour faire court : un fichier package.json sert à définir les métadonnées d'un projet, gérer ses dépendances, configurer ses scripts de lancement, et faciliter son exécution/publication. Il est donc, en quelque sorte, le cœur organisationnel de tout projet Javascript/TypeScript. Voici ce qu'il permet de faire, plus en détails.

Fournir des métadonnées à un projet

Le package.json contient avant tout des informations décrivant votre projet. Le plus souvent, on retrouve le nom du projet, sa version, une description, … mais pas seulement ! Du coup, voici une liste "exhaustive" des champs couramment utilisés au titre des métadonnées, avec leur rôle (à noter que les noms de champs sont en anglais, alors il faut faire avec !) :

• name (requis) : nom de votre package/app/projet (chaîne de caractères sans espaces, généralement en minuscules, pouvant inclure des traits d'union "-" ou tiret bas "_"). Exemple : "name": "mon-projet"
• version (requis) : version de votre projet (chaîne au format x.y.z, avec x la numérotation majeure, y la numérotation mineure, et z la numérotation des petits correctifs). Exemple : "version": "12.3.46"
• description : brève description décrivant votre projet et son but. Exemple : "description": "Une API REST NodeJS/TypeScript pour gérer des utilisateurs"
• keywords : tableau de mots-clés, permettant d'améliorer la visibilité du package sur npm. Exemple : "keywords": ["utilitaire", "gestion", "node"]
• homepage : URL de la page d'accueil ou du site web de votre projet. Par exemple : "homepage": "https://lecoints.fr/"
• license : type de licence de votre projet/package. Exemple : "license": "MIT" (pour une licence de type MIT)
• author : auteur ou entité principale derrière le package. Exemple : "author": "Jean SAIRIEN <jean.sairien@example.com> (https://js.example.com)"
• contributors : tableau de contributeurs (à l'image de author, mais sous forme de tableau). Exemple : "contributors": ["Hélène SAITOUT <helene.saitout@example.com>", "Philippe SAIPOAH <philippe.saipoah@example.com>"]
• repository : définit l'emplacement du dépôt de code source du projet. Exemple : "repository": "https://github.com/LeCoinTS/MiniChatBot"
• funding : champ d'information sur le financement du projet (soutien via dons, Patreon, etc). Exemple : "funding": "https://www.paypal.com/donate/?hosted_button_id=VEGFMQ5ZQL88W"
• private : indique si le package est privé (non publié sur npm) ou pas. Exemple : "private": true
• directories : définit des répertoires spécifiques du package, comme par exemple le répertoire où se situe la documentation, ou les fichiers exécutables. À noter que cela est régit par des clefs, telles que lib (pour les librairies), bin (pour les exécutables), man (pour les manuels), doc (pour la documentation), example (pour un répertoire contenant des exemples). Exemple : "directories": { "lib": "./lib", "doc": "./docs" }

À noter qu'il y en a peut-être d'autres, que j'ai oublié ! Mais je pense que les principaux sont ici 🙂

Fournir les dépendances

Dans un fichier package.json, les dépendances définissent les packages externes nécessaires au fonctionnement ou au développement d’un projet Node.js. À noter qu'il y a plusieurs types de dépendances (de base, pour le développement, etc), et que chaque type de dépendance a un rôle spécifique (en fait, leur configuration affecte l’installation, l’exécution, et la publication de votre projet, donc prêtez-y attention !).

Voici un exemple de dépendances déclarées dans package.json, pour un petit projet de serveur web express, écrit en TypeScript :

"dependencies": {
  "express": "^5.1.0"
},
"devDependencies": {
  "@types/express": "^5.0.1",
  "typescript": "^5.8.3"
}

Ici, on a mis le package "express" dans les dépendances (dependencies), et les "types express" et "typescript" dans les dépendances de développement (devDependencies). Car dans le code final JS, après compilation des fichiers TS, nous n'aurons besoin que du package express (les types ne servant que lors du développement, avant compilation des fichiers, et "disparaissant" après).

De manière plus générale, voici la liste des différents types de dépendances, que l'on retrouve le plus couramment :

• dependencies : ce sont les dépendances normales/de base, qui sont essentielles et requises pour que le projet fonctionne en production (c’est-à-dire dans son environnement d’exécution final)
• devDependencies : ce sont les packages uniquement nécessaires pendant le développement ou les tests, mais pas en production. Par exemple, on y retrouve donc le package "typescript", pour les projets TypeScript. Mais je me répète, pour que ce soit bien clair : ces packages ne seront pas inclus dans l’application finale, déployée en production (car seulement utiles pendant les phases de test ou dev)
• peerDependencies : ce sont les packages que le projet s’attend à trouver dans l’environnement de l’utilisateur, mais qu’il n’installe pas lui-même. En clair : l’utilisateur doit lui-même installer les packages correspondants dans ses propres dependencies (ce qui se fait de manière automatique je crois, à présent, avec npm), évitant ainsi des duplications ou conflits de versions. En fait, c'est utile si par exemple votre package doit s'intégrer dans un autre, car dans ce cas, vous pourriez faire appel à 2 versions différentes d'un autre package (React, par exemple) ; du coup, il y aurait un conflit, d'où l'utilité de peerDependencies
• optionalDependencies : ce sont les packages qui, s’ils ne peuvent pas être installés, n’empêcheront pas l’installation ou le fonctionnement du projet

Comme pour les métadonnées, il y a d'autres dépendances ici que je n'ai pas couvert, qui sont moins courant d'usage.

Nota : pour ceux qui ne comprendraient pas la différence entre dependencies et peerDependencies, voici une autre façon de présenter les choses :
- il faut mettre dans "dependencies" les packages que notre code utilise en interne, c'est à dire que l’utilisateur n’a pas besoin de connaître ou de fournir (par exemple axios pour des requêtes HTTP, lodash pour des utilitaires, et mathjs pour des calculs)
- il faut mettre dans "devDependencies" les packages qui sont par exemple un framework ou une bibliothèque principale que l’utilisateur utilise déjà (comme React, Vue, ou Angular) ; car dans ce cas, il est important de partager la même copie de ces packages là, pour éviter les bugs
Si je fais une analogie culinaire, on pourrait dire que dans "dependencies" on mettrait les ingrédients (farine, sucre, œufs, etc, pour un gâteau, par exemple), et dans "devDependencies on mettrait les ustensiles (fourchette et assiette, par exemple, qu'il n'est pas nécessaire d'avoir en double). En espérant que ce soit plus clair, exprimé ainsi 😉

Fournir des scripts personnalisés

Le champ "scripts" est une autre section importante du fichier package.json ; car cela permet de définir des commandes personnalisées, pour automatiser des tâches (compiler le code, vérifier les typages, etc). Pour que ce soit plus parlant, voici un exemple de scripts pour fichier package.json (issus d'un projet de mini webserveur express, codé en TypeScript) :

"scripts": {
  "clean": "rimraf dist",
  "build": "npm run clean && tsc",
  "start": "npm run build && node ./dist/index.js"
},

Pour faire simple, cela permet de créer 3 commandes exécutables avec npm, qui seront :

• npm run clean (qui effacera le dossier dist, grâce au programme "rimraf")
• npm run build (qui permettra de compiler les fichiers TypeScript, grâce au compilateur "tsc")
• npm run start (qui permettra de démarrer ce mini serveur web, grâce au programme "node")

Vous noterez au passage que, à l'intérieur de ces scripts, on peut faire appel à d'autres scripts. Par exemple ici : "build" fait appel à "clean" (ce qui permet d'effacer le répertoire "dist", avant d'y mettre les nouveaux fichiers compilés par "tsc") ; de même, "start" fait appel à "build" (ce qui permet d'exécuter "clean", faire un "build", et puis exécuter NodeJS en ciblant le fichier compilé "index.js"). Sympa, non ?

Du reste, en dehors de ces commandes "de base", on peut ajouter tout plein d'autres scripts très utiles, dans le fichier package.json, comme :

• "lint": "eslint src/**/*.ts" pour "linter" (vérifier le code TS avec ESLint, si vous préférez) pour détecter d'éventuelles erreurs ou incohérences dans vos fichiers TypeScript
• "test": "jest" pour faire des tests unitaires en utilisant Jest (à remplacer par "test": "vitest --run" pour ceux qui préfèrent Vitest, etc)
• "typecheck": "tsc --noEmit" pour vérifier les types TypeScript, sans générer de fichiers de sortie
• "build:types": "tsc --emitDeclarationOnly" pour générer les types de votre projet (utile si vous créez une bibliothèque TypeScript à publier sur NPM, par exemple)

Et y'en aurait plein d'autres ! En fait, vous pouvez en créer autant que vous voulez, et au passage, en leur donnant le nom que vous voulez (par exemple, si "start" ne vous plaît pas, rien ne vous empêche de le remplacer par "demarrer" !).

Pourquoi le package.json est essentiel ? Car sans ce fichier, gérer les dépendances serait un cauchemar ! Car il faudrait se rappeler de chaque bibliothèque à installer, et les installer une à une (ce qui serait long et fastidieux, et qui plus est, source d'erreurs). Les scripts automatisés, quant à eux, sont tout aussi importants, car ils permettent de réduire les tâches répétitives, augmentant ainsi la productivité. Au final, un fichier package.json permet d'avoir un projet bien encadré, reproductible (via git clone), et facile à maintenir (que vous travailliez seul, ou en équipe !). Alors mieux vaut toujours en avoir un à la racine de ses projets !

Créer un package.json pour un Projet TypeScript (étape par étape)

Voyons maintenant comment créer et configurer un fichier package.json pour un projet TypeScript. Ce petit guide, étape par étape, vous montrera comment initialiser un projet, ajouter des dépendances, et définir des scripts pour compiler et exécuter votre code. Suivez toutes ces étapes, et vous obtiendrez un package.json robuste et adapté 😉

Étape 1/5 : Initier un projet

Commençons par créer un dossier pour notre projet. Pour ce faire, ouvrons un terminal, et tapons ceci dedans :

mkdir mon-projet-typescript
cd mon-projet-typescript
npm init -y

La commande "mkdir" permet de créer un répertoire là où on est, et "cd" de rentrer dedans. Ensuite, la commande "npm init -y" permet de générer un fichier "package.json", avec des valeurs par défaut dedans (comme le nom du projet, basé sur le dossier, la version 1.0.0, et une description vide). Voici à quoi ressemble le fichier, pour l'instant :

{
  "name": "mon-projet-typescript",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "type": "commonjs"
}

Par la suite, nous allons personnaliser ces champs, selon nos besoins ! Alors suivez le guide !

Étape 2/5 : Ajouter TypeScript dans un projet

Ensuite, pour ajouter le compilateur TypeScript localement dans son projet, il suffit de taper la commande suivante :

npm install -D typescript

À ce stade, ceci s'est rajouté dans notre fichier package.json :

"devDependencies": {
  "typescript": "^5.8.3"
}

Remarque : les numéros de version peuvent être différents chez vous, selon à quel moment vous lirez ces lignes !

Au passage, comme nous utilisons TypeScript, il faudra créer un fichier de configuration pour le compilateur tsc. Pour ce faire, voici un exemple de fichier à mettre à la racine de votre projet, sous le nom de "tsconfig.json" (cela dira à "tsc" où trouver ses fichiers, et ce qu'il doit faire et comment le faire) :

{
  "compilerOptions": {
    "target": "ESNext",
    "module": "ESNext",
    "outDir": "./dist",
    "strict": true,
    "esModuleInterop": true,
    "moduleResolution": "node",
    "noImplicitAny": true
  },
  "include": ["src"],
  "exclude": ["dist", "node_modules"]
}

Pour en savoir plus sur le fichier tsconfig.json, je vous renvoie vers cet article détaillé, que je vous avais fait auparavant.

Étape 3/5 : Configurer les scripts

À présent, nous allons nous occuper des scripts de notre package.json ! Tout d'abord, il vaut supprimer la ligne "test" qui est présente dans les scripts de notre package.json "générique", créé un peu plus haut. Ensuite, il faudra rajouter des lignes, afin de pouvoir compiler (build) notre projet, et l'exécuter (start). Du coup, voici à quoi ressemblera notre fichier package.json, une fois remanié en ce sens :

Ceci permet de rajouter 2 commandes en ligne à votre projet, exécutables à la racine : npm run build pour compiler votre projet (en exécutant "tsc"), et npm run start pour lancer votre projet NodeJS (en exécutant "node").

Étape 4/5 : Ajouter des dépendances

Supposons que nous développions une petite API, reposant sur Express (une bibliothèque ultra populaire, permettant de créer des serveurs web). Nous allons donc installer Express, ainsi que ses types pour TypeScript. Cela peut se faire à l'aide des commandes suivantes :

npm install express
npm install -D @types/express

Cela va nous permettre d'installer le package "express" dans notre projet, avec ses types TS dans la foulée. Ils apparaîtront respectivement dans la section dependencies et devDependecies (du fait du "-D" lors de l'appel de la commande "npm"), dans notre fichier "package.json".

Pour ne pas perdre le fil, voici à quoi ressemble package.json, une fois ces dépendances installées :

{
  "name": "mon-projet-typescript",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "build": "tsc",
    "start": "node dist/index.js"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "type": "commonjs",
  "devDependencies": {
    "@types/express": "^5.0.1",
    "typescript": "^5.8.3"
  },
  "dependencies": {
    "express": "^5.1.0"
  }
}

Voilà, on est presque au bout !

Étape 5/5 : Finaliser le package.json

Maintenant, il nous reste plus qu'à compléter notre package.json avec des métadonnées comme l’auteur, la licence, et une description claire. Voici un exemple de ce que pourrait donner un projet TypeScript avec Express, au niveau du fichier package.json :

{
  "name": "mon-projet-typescript",
  "version": "1.0.0",
  "description": "Un projet TypeScript avec Express",
  "main": "dist/index.js",
  "scripts": {
    "build": "tsc",
    "start": "node dist/index.js"
  },
  "keywords": [],
  "author": "Votre Nom",
  "license": "MIT",
  "type": "commonjs",
  "devDependencies": {
    "@types/express": "^5.0.1",
    "typescript": "^5.8.3"
  },
  "dependencies": {
    "express": "^5.1.0"
  }
}

Ce fichier est prêt pour un projet TypeScript fonctionnel. Il ne vous reste plus qu'à créer un fichier src/index.ts, par exemple, puis écrire du code dedans ! Enfin, la commande npm run build vous permettra de le compiler, et npm run start de l'exécuter !

Et voici ce que ça donnerait, sous VScode :

Remarque : ici, j'ai volontairement simplifié les choses et pris un cas basique, afin que vous puissiez prendre des repères, en programmation TypeScript. Après, si vous souhaitez voir des programmes TS plus fournis, n'hésitez pas à faire un saut dans la rubrique Projets Pratiques de ce site ! Car c'est fait pour !

Questions fréquentes, au sujet de package.json

Tant que j'y pense, je vais vous lister ici plusieurs questions qu'on se pose au sujet de package.json, tôt ou tard ! Les voici :

• Puis-je modifier manuellement le package.json ? Oui, vous pouvez éditer le package.json directement, que ce soit pour renseigner/mettre à jour des métadonnées, ajouter/retirer/changer des dépendances, ajouter/modifier/supprimer des scripts, etc. Une remarque, cependant : vérifiez bien que la syntaxe JSON soit toujours correcte (pas de virgule ou de guillemets manquants, par exemple). En outre, un validateur JSON ou un éditeur avec linting permet d'éviter ce genre d'erreurs (perso, c'est mon cas sous VS Code, qui signale la moindre erreur JSON dans ce fichier).
• Que faire si npm install échoue ? Si la commande npm install échoue, cela peut être dû à un cache corrompu, à un problème de réseau, ou à un conflit dans le package-lock.json. Dans ce cas, supprimez le répertoire node_modules et le fichier package-lock.json, exécutez npm cache clean --force pour vider le cache, et faites un npm install pour relancer l'installation. Cela permet de régénérer les dépendances, et résout la plupart du temps les problèmes !
• Quelle est la différence entre dependencies et devDependencies ? Les "dependencies" listent toutes les bibliothèques nécessaires pour exécuter votre application en production (c'est à dire finalisée, en ligne). Les "devDependencies", quant à elles, listent tous les outils utilisés uniquement en développement (comme typescript, par exemple !).

Nota : et si je pense à d'autres questions/réponses plus tard, je vous les rajouterai ici 🙂

Qu’est-ce que le fichier package-lock.json, et à quoi il sert ?

Peut-être l'avez vous déjà remarqué ou pas, mais à moment donné, un fichier package-lock.json est automatiquement créé, aux côtés du fichier package.json. Mais savez-vous ce qu'est ce fichier, et à quoi il sert ?

Dit simplement, le fichier package-lock.json contient (et verrouille) les versions exactes des dépendances installées dans un projet, y compris leurs sous-dépendances. En fait, lorsque vous exécutez npm install ou modifiez le fichier package.json (en ajoutant une dépendance, par exemple), alors npm met à jour ce fichier pour enregistrer les versions précises des packages installés. Voici un exemple simplifié de "package-lock.json" :

{
  "name": "mon-projet-typescript",
  "version": "1.0.0",
  "lockfileVersion": 2,
  "requires": true,
  "packages": {
    "": {
      "dependencies": {
        "express": "^4.18.2"
      }
    },
    "node_modules/express": {
      "version": "4.18.2",
      "resolved": "https://registry.npmjs.org/express/-/express-4.18.2.tgz"
    }
  }
}

Pour bien comprendre ce qui le différencie de package.json, il suffit de jeter un coup d'oeil aux versions dans chacun des deux fichiers. Et là, vous vous apercevrez vite que "package.json" utilise une plage de versions (par exemple "express": "^4.18.2", pour dire qu'on veut la version 4.18.2 ou plus d'express), alors que "package-lock.json" utilise des versions fixes/définies/exactes (par exemple "version": "4.18.2", pour dire qu'on veut EXACTEMENT la version 4.18.2 et pas une autre, pour le package express de l'exemple ci-dessus).

En terme de traçabilité, par ailleurs, package-lock.json offre une vue détaillée des packages installés, de leurs sources, et de leurs sous-dépendances. Ainsi, il complète parfaitement le fichier "package.json". En résumé : le package.json définit les dépendances et leurs plages de versions, tandis que le package-lock.json enregistre les versions exactes installées. Ensemble, ils assurent un environnement TypeScript stable, et prévisible.

Attention/important : ne modifiez jamais manuellement le fichier package-lock.json, car c'est le gestionnaire de paquet (npm, par exemple) qui s'en charge uniquement. Car toute modification manuelle peut causer des incohérences, et donc, des plantages par la suite.

Conclusion

Nous voila arrivé à la fin de cet article ! Si cela vous paraît trop compliqué, retenez simplement que le fichier package.json est un pilier essentiel des projets TypeScript. Que vous le créiez manuellement ou avec "npm init", il centralise la gestion des dépendances, des scripts, et des métadonnées, rendant votre projet structuré et facile à maintenir. En sachant que les scripts vous permettent d’automatiser des tâches comme la compilation ou le lancement de l’application, tandis que le package-lock.json garantit une reproductibilité parfaite des installations.

Si cet article vous a plû, n'hésitez pas à le faire savoir en commentaire, et un café (don symbolique) sera toujours le bienvenu ! (en cliquant sur le bouton jaune, ci-dessous).

Merci à vous, et à bientôt !
Jérôme.

(*) Mis à jour le 10/08/2025