update developer documentation in French

docs/fr/for-developers/barcodes.md

@@ -0,0 +1,44 @@
+# Codes-barres
+
+Les codes-barres constituent un mécanisme efficace pour récupérer des documents avec une intervention minimale de l'utilisateur. BHIMA génère des codes-barres pour chaque reçu produit. Ce document décrit le fonctionnement des codes-barres dans BHIMA.
+
+## Conventions de dénomination des enregistrements
+
+_Note: il serait peut-être préférable de le mettre ailleurs_
+
+En interne, BHIMA utilise la version 4 [universally unique identifiers (UUIDs)](https://en.wikipedia.org/wiki/Universally_unique_identifier#Version_4_.28random.29) comme clé primaire pour la plupart des enregistrements. Bien qu’ils présentent de nombreux avantages, être lisibles par l’homme n’en fait pas partie. Afin de faire référence facilement et de manière significative aux documents, nous avons développé une « référence » lisible par l'homme composée avec la syntaxe suivante :
+
+```
+${type}.${project}.${integer}
+```
+
+où `${type}` est le type de document à deux lettres, `${project}` est l'abréviation du projet qui a créé le document et `${integer}` est un identifiant entier croissant de manière monotone. Quelques exemples de ces références peuvent être « IV.TPA.123 », « VO.XYZ.333 », etc.
+
+Les types suivants sont codés en dur dans le système :
+
+1. `IV` -> Facture
+2. `VO` -> Bon
+3. `CP` -> Paiement en espèces
+4. `SM` -> Mouvement de stock
+5. `PA` -> Carte patient
+
+Ainsi, la référence `PA.NXR.3` se lit comme "le troisième patient du projet NXR". De même, `VO.UOU.39410` est le "39410ème bon du projet UOU".
+
+## Génération de codes à barres
+
+Semblables aux références lisibles par l’homme, les codes-barres générés par le système ont une syntaxe spécifique. C'est:
+
+```
+${type}${8 premiers caractères de l'UUID}
+```
+
+Par exemple, un code-barres peut être `IVBBA182AF` qui désigne la _facture_ avec les 8 premiers caractères de l'uuid comme **BBA182AF**. Le code se trouve dans [server/lib/barcode.js](https://github.com/IMA-WorldHealth/bhima/blob/master/server/lib/barcode.js).
+
+
+Pourquoi utiliser 8 caractères ? Parce que les codes-barres sont larges et qu’il nous fallait un format adapté à un ticket thermique de 80 mm tout en restant lisible. Malgré leur obscurcissement, les codes-barres sont un alphabet, lu de gauche à droite. Plus de caractères créent un « mot » de code-barres plus long. Il est intéressant de noter que les codes QR ne présentent pas ce problème : ils augmentent plutôt la complexité du modèle de code QR. Mais les lecteurs de codes QR sont chers alors que les lecteurs de codes-barres sont bon marché.
+
+## Comment les codes-barres sont lus dans BHIMA
+
+Un lecteur de codes-barres se comporte comme un clavier. BHIMA utilise un composant de lecture de codes-barres (trouvé dans [client/src/modules/templates/bhBarcodeScanner.html](https://github.com/IMA-WorldHealth/bhima/blob/master/client/src/modules/templates/bhBarcodeScanner.html)) pour faire tout le travail de lecture du code-barres. Le lecteur de code-barres renverra le `uuid` de l'enregistrement numérisé. C'est au contrôleur du module de déterminer ce qui doit se passer ensuite (rendre un reçu, le joindre à un objet, charger l'enregistrement depuis la base de données, etc.).
+
+Étant donné qu'un lecteur de codes-barres se comporte comme un clavier, vous n'avez pas besoin d'un lecteur de codes-barres pour simuler une lecture de code-barres. Copier simplement une chaîne, ouvrir le composant de lecture de code-barres et coller (C-V) déclenchera la lecture avec le contenu que vous avez collé. Ceci est très utile lors du développement lorsque les lecteurs de codes-barres ne sont pas pratiques.

docs/fr/for-developers/end-to-end-tests.md

@@ -0,0 +1,23 @@
+# Tests de bout en bout
+
+BHIMA dispose d'une large collection de tests de bout en bout utilisant le [Environnement de test de Playwright](https://playwright.dev/docs/intro).  Les directives suivantes pour faire fonctionner les tests dans votre environnement.  Cette description suppose que vous avez déjà configuré l'environnement de développement BHIMA (voir [Installation](./installing-bhima.md)).
+
+1. Installer Playwwright:
+```bash
+  npm install playwright
+```
+
+2. Vérifiez que tout est cohérent. Les commandes suivantes doivent donner les mêmes numéros de version :
+```bash
+  grep 'playwright/test' yarn.lock   # si vous utilisez yarn
+  grep 'playwright/test' package.json
+  npx playwright --version
+```
+
+3. Installer les navigateurs requis par Playwright
+```bash
+  npx playwright install
+```
+NOTE:  Si vous mettez à niveau votre version de Playwright dans votre sandbox, vous devrez peut-être réexécuter cette commande pour mettre à jour les navigateurs de Playwright.
+
+4. Exécutez les tests de bout en bout (voir `package.json` pour les commandes).

docs/fr/for-developers/index.md

@@ -3,3 +3,7 @@
 Cette section fournit des conseils et astuces utiles pour que les développeurs soient rapidement opérationnels.
 
 1. [Installation](./installing-bhima.md)
+2. [Déploiement en production avec systemd](./production-deployment-with-systemd.md)
+3. [Mise à niveau d'une installation existante](./upgrading-bhima.md)
+3. [Tests de bout en bout](./end-to-end-tests.md)
+4. [Remarques sur les codes-barres](./barcodes.md)

docs/fr/for-developers/production-deployment-with-systemd.md

@@ -0,0 +1,161 @@
+# Déploiement en production avec Systemd
+
+Ce guide vous expliquera le déploiement de BHIMA à l'aide de systemd pour la gestion des processus et des journaux et d'un nginx pour équilibrer la charge entre plusieurs instances de nodejs. Ces instructions ont été testées sur Ubuntu 20.04.
+
+### Gestion des processus avec SystemD
+
+Créez un fichier appelé `bhima@.service` dans le répertoire `/etc/systemd/system/`.  C'est un [systemd unit file](https://www.freedesktop.org/software/systemd/man/systemd.unit.html) qui démarrera BHIMA sur un port spécifié. En supposant que l'utilisateur est `bhima` et que l'installation de BHIMA se trouve dans `/home/bhima/apps/bhima`,le contexte du fichier sera:
+
+```systemd
+# bhima@.service
+[Unit]
+Description=The bhima server
+Documentation=https://docs.bhi.ma
+After=network.target
+
+[Service]
+Environment=NODE_ENV=production PORT=%i
+Type=simple
+User=bhima
+
+# adjust this accordingly
+WorkingDirectory=/home/bhima/apps/bhima/bin/
+
+# adjust this accordingly
+ExecStart=/usr/bin/node server/app.js
+Restart=on-failure
+
+[Install]
+WantedBy=multi-user.target
+```
+
+[Plus d'information](https://www.freedesktop.org/software/systemd/man/systemd.syntax.html) sur la syntaxe des fichiers unités. Une fois le fichier en place, vous devez recharger le démon systemd.
+
+```bash
+systemctl daemon-reload
+```
+
+
+### Équilibrage de charge avec Nginx
+
+Dans cet exemple, nous équilibrerons la charge sur trois serveurs nodejs en aval. Cependant, la meilleure pratique consiste à utiliser un maximum de processus `$(nproc - 1)`. Ajustez le fichier suivant en conséquence.
+
+Créez un nouveau fichier de configuration nginx nommé `bhima` dans `/etc/nginx/sites-available/`.  Mettez la configuration suivante dans ce fichier:
+
+```nginx
+upstream bhima {
+
+  # assurez-vous d'acheminer les requêtes vers le serveur qui a le moins de connexions
+  # http://nginx.org/en/docs/http/load_balancing.html
+  least_conn;
+
+  # changez ces ports en fonction de ce que vous souhaitez équilibrer la charge
+	# ajoutez/supprimez un serveur selon vos besoins. Ici, nous avons trois serveurs nodejs en aval
+  server 127.0.0.1:3001;
+  server 127.0.0.1:3002;
+  server 127.0.0.1:3003;
+}
+
+
+# Serveur d'équilibrage de charge
+server {
+
+ # ajouter la configuration gzip (si vous le souhaitez)
+ include includes/gzip.conf;
+
+ # opt out of Google's FLOCK.
+ add_header Permissions-Policy interest-cohort=();
+
+ server_name _;
+
+ # pass data to upstream server
+ location / {
+   proxy_pass http://bhima;
+   proxy_http_version 1.1;
+   proxy_set_header Upgrade $http_upgrade;
+   proxy_set_header Connection 'upgrade';
+   proxy_set_header Host $host;
+   proxy_cache_bypass $http_upgrade;
+  }
+}
+```
+
+Pour être complet, le fichier `gzip.conf` situé dans `/etc/nginx/includes/gzip.conf` est :
+
+```nginx
+gzip on;
+gzip_disable "msie6";
+
+gzip_vary on;
+gzip_proxied any;
+
+gzip_comp_level 5;
+gzip_buffers 16 8k; # see http://stackoverflow.com/a/5132440
+gzip_http_version 1.1;
+gzip_min_length 128;
+
+gzip_types
+        application/atom+xml
+        application/javascript
+        application/json
+        application/ld+json
+        application/manifest+json
+        application/octet-stream
+        application/rss+xml
+        application/vnd.geo+json
+        application/vnd.ms-fontobject
+        application/x-font-ttf
+        application/x-javascript
+        application/x-web-app-manifest+json
+        application/xhtml+xml
+        application/xml
+        font/opentype
+        image/bmp
+        image/svg+xml
+        image/x-icon
+        text/cache-manifest
+        text/css
+        text/javascript
+        text/plain
+        text/vcard
+        text/vnd.rim.location.xloc
+        text/vtt
+        text/x-component
+        text/x-cross-domain-policy
+        text/xml;
+```
+
+Ce fichier configure un équilibre de charge qui transmet les requêtes à trois serveurs en aval sur les ports 3001, 3002 et 3003. Créez un lien symbolique entre `/etc/nginx/sites-available/bhima` dans `/etc/nginx/sites-enabled/bhima ` pour s'assurer qu'il est actif. Testez la configuration nginx, puis rechargez :
+
+```bash
+# tester la configuration
+nginx -t
+
+# recharger la configuration
+systemctl reload nginx
+```
+
+### Déploiement et redémarrage automatique
+
+La touche finale au déploiement consiste à configurer le démarrage automatique au démarrage. Cela se fait facilement avec `systemctl activate bhima@${PORT}` où `${PORT}` est le port souhaité sur lequel exécuter BHIMA. Faites cela pour chaque serveur en aval.
+
+```bash
+# démarrer le serveur nodejs
+systemctl start bhima@3001
+
+# activer le démarrage au démarrage.
+systemctl enable bhima@3001
+```
+
+Lorsque vous curl `http://localhost`, vous devriez maintenant accéder au serveur BHIMA via nginx.
+
+### Gestion des journaux
+
+Parce que nous utilisons systemd, les journaux sont gérés avec [journald](https://www.man7.org/linux/man-pages/man8/systemd-journald.service.8.html).  Pour surveiller les journaux des serveurs ci-dessus, la ligne suivante affichera les journaux en temps réel :
+
+```bash
+# suivez et suivez tous les journaux de bhima
+journalctl -u bhima@* --follow
+```
+
+Il peut être important, lors d'une installation avec un espace disque faible, d'ajuster la `SystemMaxUse` et `SystemMaxFileSize` paramètres dans `/etc/systemd/journald.conf`.

docs/fr/for-developers/upgrading-bhima.md

@@ -0,0 +1,45 @@
+# Mise à niveau de BHIMA
+
+Cette page fournit des notes sur le fonctionnement des mises à niveau de BHIMA. Notez que ces étapes sont assez manuelles, et nous aimerions les automatiser à l'avenir.
+
+## Versions BHIMA
+
+BHIMA utilise les balises git pour baliser les modifications sur la branche principale et [Versions de Github](https://help.github.com/en/github/administering-a-repository/managing-releases-in-a-repository) pour supprimer les versions.  La dernière version est toujours la dernière balise/version sur git et Github respectivement.  La [dernière version](https://github.com/IMA-WorldHealth/bhima/releases/latest) est toujours disponible à partir du lien `https://github.com/IMA-WorldHealth/bhima/releases/latest`.
+
+Bien que git gère efficacement les modifications avec le code, certaines modifications nécessitent des modifications des données de production sous-jacentes - par exemple, l'ajout d'une colonne à une table de base de données, la réaffectation de clés étrangères, etc. Ces modifications sont conservées dans le répertoire `server/models/migrations/` dans le référentiel BHIMA. Dans ce répertoire se trouvent une série de dossiers, nommés sous la forme `v.old.release-v.new.release`.  Ils contiennent un seul fichier SQL (généralement appelé `migrate.sql`) qui est nécessaire pour passer de `v.old.release` à `v.new.release`.  Par exemple, le fichier `v1.12.1-v1.13.0/migrate.sql` migrerait la base de données de la version `1.12.1` vers la version `1.13.0`.
+
+Les nouvelles modifications (par exemple les modifications non publiées) sont conservées dans le dossier `server/models/migrations/next/`. En préparation d'une nouvelle version, ces modifications sont combinées et renommées dans le format `v.old-release-v.new-release` décrit ci-dessus.
+
+Remarque : toutes les versions ne nécessitent pas de modifications des structures de données. Par conséquent, toutes les modifications de version n'auront pas un fichier `migrate.sql` associé.
+
+Lors de la mise à niveau d'une ancienne version vers une nouvelle version, il est important d'exécuter tous les fichiers `migrate.sql` _dans l'ordre_ du plus ancien au plus récent. Malheureusement, une fois entrés, ces fichiers échouent sur une base de données de production où des modifications ont été apportées sans vérifier dans le code source la structure des données. S'il vous plaît laissez-nous savoir si vous trouvez cela.
+
+## Notes sur les migrations de bases de données
+
+Les modifications apportées aux procédures stockées, aux déclencheurs et aux fonctions ne sont **pas** suivies dans les scripts de migration. En effet, ils sont dus à des changements fréquents et sont déjà stockés dans le répertoire `server/models`. Il suffit donc simplement de les reconstruire à partir des sources.
+
+Pour faciliter cette opération, BHIMA fournit un [script d'aide à la migration](https://github.com/IMA-WorldHealth/bhima/blob/master/sh/setup-migration-script.sh) qui peut être invoqué avec `yarn migrate`. Ce script fait plusieurs choses :
+
+1. Supprime tous les déclencheurs
+2. Supprime toutes les routines
+3. Combine les déclencheurs, les fonctions et les procédures de la source
+4. Écrit les données dans le fichier `migration-$DATABASE.sql`
+
+où `$DATABASE` est le nom de la base de données de production. Maintenant que les données sont écrites, elles peuvent être exécutées sur la base de données de production avec la commande `mysql $DATABASE < migration-$DATABASE.sql`. Comme pour toutes les opérations sur les bases de données de production, _prenez toujours d'abord un instantané de sauvegarde._
+
+## Obtenir la dernière version
+
+Comme mentionné ci-dessus, les versions sont gérées sur Github. Il existe deux façons d'obtenir la dernière version : soit en téléchargeant un répertoire compressé depuis Github, soit en utilisant git pour extraire les dernières modifications et consulter la dernière balise.  Si vous avez déployé [à Digital Ocean](../getting-started/deploying-digital-ocean.md), le déploiement a été effectué via un téléchargement zip et vous devez utiliser cette méthode. La plupart des déploiements de développement sont effectués avec git et il suffit de vérifier la dernière version.
+
+## Étapes de mise à niveau
+
+Les étapes de base pour mettre à niveau maintenant sont :
+
+1. Obtenez la dernière version en téléchargeant et en décompressant ou en vérifiant la balise avec git.
+2. Exécutez `yarn` pour mettre à niveau les dépendances.
+3. Exécutez `NODE_ENV=production yarn build` pour compiler le dernier code côté client
+4. Exécutez `yarn migrate` pour créer le script de migration.
+5. Exécutez `mysql $DATABASE < migration-$DATABASE.sql` comme décrit ci-dessus.
+6. Redémarrez toutes les instances BHIMA en cours d'exécution
+
+Cela devrait terminer les étapes de mise à niveau d’une installation BHIMA existante.