Pendant longtemps, il suffisait d'utiliser son adresse email et son mot de passe. Mais aujourd'hui, cette méthode ne fonctionne plus.

Google bloque désormais l'accès aux comptes Gmail depuis la plupart des applications utilisant simplement un mot de passe classique.

Heureusement, Google propose une solution : les App Passwords, ou mots de passe d'application.

Qu'est-ce qu'un App Password ?

Un App Password est un mot de passe généré par Google spécialement pour une application.

Contrairement à votre mot de passe principal :

• il est limité à un usage précis
• il peut être révoqué à tout moment
• il n'autorise pas l'accès complet à votre compte Google

L'idée est de permettre à une application de se connecter à Gmail sans lui donner votre véritable mot de passe.

Générer un App Password

Activer l'authentification à deux facteurs

Avant de pouvoir créer un App Password, vous devez activer la validation en deux étapes sur votre compte Google.

Rendez-vous dans les paramètres de sécurité de votre compte Google puis activez l'authentification à deux facteurs.

Sans cette étape, le menu des App Passwords n'apparaîtra pas.

Créer un mot de passe

Une fois l'authentification à deux facteurs activée :

• ouvrez les paramètres de sécurité Google
• recherchez la section "Mots de passe des applications"
• créez un nouveau mot de passe
• choisissez un nom comme "Serveur SMTP" ou "Application NodeJS"

Vous pouvez aussi cliquer sur le lien direct : https://myaccount.google.com/apppasswords

Google génère alors une chaîne ressemblant à ceci :

abcd efgh ijkl mnop

C'est ce mot de passe qu'il faudra utiliser dans votre application.

Utiliser votre App Password

Configuration SMTP

Pour envoyer des emails avec Gmail, utilisez les paramètres suivants :

Serveur SMTP : smtp.gmail.com
Port : 587
Sécurité : TLS / STARTTLS
Utilisateur : <votre-adresse@gmail.com>
Mot de passe : <votre_app_password>

Configuration IMAP

Si vous souhaitez recevoir ou lire des emails, vous devrez utiliser IMAP.

Les paramètres sont les suivants :

Serveur IMAP : imap.gmail.com
Port : 993
Sécurité : SSL/TLS
Utilisateur : votre-adresse@gmail.com
Mot de passe : <votre_app_password>

Les limites de Gmail

Même si Gmail fonctionne très bien pour des tests ou de petits projets, il ne remplace pas un véritable service d'envoi transactionnel.

Google applique notamment :

• des limites d'envoi quotidiennes
• des contrôles anti-spam
• des restrictions sur certains usages automatisés

Pour un projet professionnel ou une application à fort volume, des solutions comme Brevo (français), Resend, Mailgun ou SendGrid seront généralement plus adaptées.

Notre article dédié pour l’envoi d’email en Node.js

Mais il existe aussi beaucoup de cas où l’on veut faire l’inverse : lire les emails reçus.

Par exemple, pour traiter automatiquement des demandes entrantes, récupérer des pièces jointes, analyser des réponses clients, ou déclencher une action lorsqu’un message arrive dans une boîte spécifique.

Pour cela, on utilise généralement un protocol dédié : IMAP (Internet Message Access Protocol).

IMAP permet à une application de se connecter à une boîte mail pour lire, parcourir et manipuler les messages.

En Node.js, deux bibliothèques sont particulièrement pratiques pour ce besoin : ImapFlow et MailParser.

ImapFlow est un client IMAP moderne pour Node.js, avec une API basée sur les Promises et async/await (documentation officielle).

MailParser, de son côté, permet de transformer un email brut en objet JavaScript exploitable. Sa fonction simpleParser est pratique pour les cas simples, tandis que la classe MailParser permet de traiter les gros messages sous forme de streams (documentation officielle).

Fonctionnement

Installer les dépendances

On commence par installer les deux packages :

npm install imapflow mailparser

Si vous utilisez TypeScript, ImapFlow fournit déjà ses propres types. Pour MailParser, vous pouvez ajouter :

npm install -D @types/mailparser

Se connecter à une boîte mail

Voici un exemple avec Gmail, mais le principe est le même avec n’importe quel serveur IMAP.

import { ImapFlow } from "imapflow";

const client = new ImapFlow({
  host: "imap.gmail.com",
  port: 993,
  secure: true,
  auth: {
    user: "votre-adresse@gmail.com",
    pass: "votre-app-password",
  },
});

await client.connect();

Pour Gmail, il ne faut pas utiliser votre mot de passe principal.

Il faut générer un App Password depuis votre compte Google, puis l’utiliser comme mot de passe IMAP.

Lire les derniers emails

Une fois connecté, il faut ouvrir une boîte. La plus courante est INBOX.

const lock = await client.getMailboxLock("INBOX");

try {
  for await (const message of client.fetch("1:*", {
    envelope: true,
    source: true,
  })) {
    console.log(message.envelope.subject);
  }
} finally {
  lock.release();
}

Le lock évite que plusieurs opérations entrent en conflit sur la même boîte.

C’est une bonne habitude avec ImapFlow : on verrouille, on travaille, puis on libère.

Ici, source: true permet de récupérer l’email brut. C’est ce contenu que nous allons ensuite donner à MailParser.

Parser un email avec MailParser

Un email n’est pas un simple texte. Il peut contenir du HTML, du texte brut, des pièces jointes, des encodages différents, des headers, des destinataires, etc.

MailParser s’occupe de transformer tout cela en objet plus facile à manipuler :

import { simpleParser } from "mailparser";

for await (const message of client.fetch("1:*", {
  envelope: true,
  source: true,
})) {
  const parsed = await simpleParser(message.source);

  console.log({
    subject: parsed.subject,
    from: parsed.from?.text,
    text: parsed.text,
    html: parsed.html,
  });
}

simpleParser charge le message en mémoire.

C’est très pratique pour démarrer, mais si vous traitez de gros emails ou beaucoup de pièces jointes, il faudra plutôt utiliser l’API en streaming de MailParser.

Lire uniquement les emails non lus

Dans la vraie vie, vous ne voulez pas relire toute la boîte à chaque exécution.

Vous pouvez chercher uniquement les emails non lus :

for await (const message of client.fetch(
  { seen: false },
  { envelope: true, source: true }
)) {
  const parsed = await simpleParser(message.source);

  console.log(parsed.subject);
}

Ensuite, vous pouvez marquer le message comme lu :

await client.messageFlagsAdd(message.uid, ["\\Seen"], { uid: true });

Cela permet de construire facilement un petit worker qui traite seulement les nouveaux emails.

Exemple complet

import { ImapFlow } from "imapflow";
import { simpleParser } from "mailparser";

const client = new ImapFlow({
  host: "imap.gmail.com",
  port: 993,
  secure: true,
  auth: {
    user: process.env.MAIL_USER,
    pass: process.env.MAIL_PASSWORD,
  },
});

await client.connect();

const lock = await client.getMailboxLock("INBOX");

try {
  for await (const message of client.fetch(
    { seen: false },
    { uid: true, source: true }
  )) {
    const parsed = await simpleParser(message.source);

    console.log("Sujet :", parsed.subject);
    console.log("De :", parsed.from?.text);
    console.log("Texte :", parsed.text);

    await client.messageFlagsAdd(message.uid, ["\\Seen"], { uid: true });
  }
} finally {
  lock.release();
  await client.logout();
}

• écouter des évènements du navigateur
• gérer des états réactifs
• accéder aux APIs Web
• nettoyer des listeners

C’est précisément le problème que résout VueUse.

Une bibliothèque de composables

VueUse est une immense bibliothèque de composables prêts à l’emploi pour Vue.js.

Elle propose des centaines d’utilitaires pour :

• le navigateur
• les animations
• les capteurs
• les raccourcis clavier
• le stockage local
• les APIs Web modernes

Et surtout tous les utilitaires sont pensés pour fonctionner naturellement avec la réactivité de Vue.

L’installation est très simple :

npm install @vueuse/core

Ensuite, vous pouvez importer uniquement les composables dont vous avez besoin.

Copier du texte avec useClipboard

L’API du presse-papiers du navigateur peut être un peu pénible à utiliser directement.

VueUse simplifie énormément cela avec useClipboard.

import { useClipboard } from "@vueuse/core"

const { copy, copied } = useClipboard()

const copyCode = async () => {
  await copy("Hello world")
}

Le booléen copied devient automatiquement true pendant quelques secondes après la copie.

Parfait pour afficher un message :

<p v-if="copied">Texte copié !</p>

C’est idéal pour :

• des boutons “Copier”
• des snippets de code
• des liens de partage
• des tokens API

Récupérer la position GPS avec useGeolocation

VueUse propose aussi un accès très simple à la géolocalisation du navigateur.

import { useGeolocation } from "@vueuse/core"

const { coords, locatedAt, error } = useGeolocation()

Les coordonnées deviennent automatiquement réactives :

<p>Latitude : {{ coords.latitude }}</p>
<p>Longitude : {{ coords.longitude }}</p>

C’est particulièrement utile pour :

• une carte interactive
• une application météo
• du contenu localisé
• du suivi de position

Et contrairement à une implémentation manuelle, VueUse gère déjà :

• les listeners
• la réactivité
• le nettoyage automatique

Détecter l’état du réseau avec useNetwork

Savoir si un utilisateur est hors ligne peut améliorer énormément l’expérience utilisateur.

Avec useNetwork :

import { useNetwork } from "@vueuse/core"

const { isOnline, downlink, effectiveType } = useNetwork()

Vous pouvez facilement afficher un message :

<p v-if="!isOnline">
  Vous êtes actuellement hors ligne.
</p>

Mais aussi adapter l’application selon la qualité du réseau.

Par exemple :

• réduire la qualité des images
• désactiver certaines animations
• éviter des requêtes lourdes

Utiliser une manette avec useGamepad

C’est probablement l’un des composables les plus amusants.

useGamepad permet d’accéder aux manettes connectées au navigateur.

import { useGamepad } from "@vueuse/core"

const { gamepads } = useGamepad()

Vous pouvez ensuite lire les boutons et axes :

<pre>{{ gamepads }}</pre>

Cela ouvre la porte à énormément de projets :

• mini jeux Vue.js
• interfaces interactives
• bornes tactiles
• contrôles alternatifs

Et tout cela avec très peu de code.

À chaque modification du module, il faudrait normalement :

• publier une nouvelle version
• réinstaller le package dans le projet de test
• relancer l’application

Heureusement, npm link existe justement pour éviter ça.

Fonctionnement

Cette commande permet de créer un lien symbolique entre un package local et un autre projet.

Autrement dit : votre projet utilise directement le code source local du module, comme s’il avait été installé depuis NPM.

Le fonctionnement se fait en deux étapes. D’abord, dans le dossier du paquet NPM :

npm link

Cette commande enregistre le package globalement sur votre machine.

Ensuite, dans le projet qui doit utiliser ce package :

npm link nom-du-package

À partir de ce moment-là, le dossier node_modules du projet pointera directement vers votre module local.

Un lien symbolique

Le gros avantage, c’est que les modifications deviennent quasiment instantanées. Vous changez du code dans votre package… et votre projet de test utilise immédiatement la nouvelle version.

Plus besoin de publier une version 0.0.1-dev-test-42.

Sous le capot, npm link utilise des liens symboliques (symlink) du système d’exploitation.

Un exemple concret

Voici un exemple pour bien comprendre la marche à suivre. Vous avez deux projets :

mon-package/
mon-app/

!!! well Dans mon-package :

npm link

!!! !!! well Puis dans mon-app :

npm link mon-package

!!!

Et voilà. Votre application utilise maintenant directement la version locale du package.

• Pourquoi ce framework a été choisi ?
• Pourquoi ce calcul fonctionne de cette manière ?
• Pourquoi utilise-t-on Redis ici, mais pas ailleurs ?

Le problème, c’est qu’avec le temps, les développeurs changent, les discussions Slack disparaissent, et les décisions prises plusieurs mois auparavant deviennent difficiles à comprendre.

C’est précisément le rôle des ADR, pour Archicture Decision Record.

Architecture Decision Record

Un ADR est un document très simple qui sert à conserver une trace d’une décision technique importante dans un projet.

L’idée n’est pas de rédiger une énorme documentation, au contraire :

Un ADR est généralement court, simple et centré sur une seule décision.

L’objectif est surtout de répondre à une question essentielle : Pourquoi cette décision a-t-elle été prise ?

Un ADR contient souvent :

• le contexte ⇒ explique le problème rencontré.
• la décision ⇒ décrit le choix effectué.
• les conséquences ⇒ détaillent les avantages, limites ou compromis associés.

Voici un exemple très simplifié :

# ADR-001 : Utilisation de PostgreSQL

## Context
Le projet nécessite des relations complexes entre les données.

## Decision
Utiliser PostgreSQL comme base principale.

## Consequences
- SQL puissant
- bonnes performances relationnelles
- infrastructure plus lourde qu’une base NoSQL

Ce type de document peut sembler anodin… mais il devient extrêmement précieux avec le temps.

Pourquoi mettre en place des ADR ?

Sans ADR, beaucoup de projets finissent avec des décisions “historiques” que plus personne ne comprend vraiment.

Et cela crée souvent des problèmes :

• duplication de solutions
• remise en question permanente
• peur de modifier certaines parties du projet
• onboarding plus difficile

Et surtout cela rend encore plus critique le fameux “bus factor”

Mettre en place des ADR est particulièrement utile dans :

• les projets longs
• les équipes qui grandissent
• les architectures complexes
• les projets open source

La bonne nouvelle, c’est qu’on peut commencer, dès aujourd’hui, sans aucun outils

Beaucoup d’équipes stockent simplement leurs ADR dans un dossier :

/docs/adr

Ou directement :

/adr

Le plus important n’est pas le format, mais de commencer à documenter le plus tôt possible.

Parce qu’en architecture logicielle, le problème n’est pas seulement de prendre de bonnes décisions. C’est aussi de comprendre, plusieurs années plus tard, pourquoi elles ont été prises.

Elles peuvent sembler similaires… mais elles n’ont absolument pas le même rôle.

À noter que si vous ne connaissez pas Docker, cet article ne vous sera pas très utile, mais vous pouvez toujours aller écouter notre introduction à Docker dans un épisode dédié du podcast !

La commande RUN

RUN est utilisé lors de la construction de l’image Docker.

Par exemple :

RUN apt-get update && apt-get install -y curl

Cette commande est exécutée :

• pendant le docker build
• pour modifier l’image

RUN sert à préparer l’image.

Chaque instruction RUN crée une nouvelle couche dans l’image Docker.

Typiquement, vous utilisez RUN pour :

• installer des dépendances
• copier ou générer des fichiers
• configurer l’environnement

La commande CMD

CMD est utilisée lors du lancement du conteneur.

Par exemple :

CMD ["node", "server.js"]

Cette commande est exécutée :

• quand vous faites docker run
• au démarrage du conteneur

CMD sert à dire : “voilà ce que fait ce conteneur quand il démarre”.

La différence clé

La différence principale tient en une phrase : RUN s’exécute pendant le build tandis que CMD s’exécute au runtime.

Autrement dit :

• RUN modifie l’image
• CMD définit le comportement du conteneur

Un exemple concret

Prenons un Dockerfile simple :

FROM node:18
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .

CMD ["node", "index.js"]

Ce qu’il se passe :

1. RUN npm install installe les dépendances dans l’image
2. CMD ["node", "index.js"] lance l’application au démarrage

Sans CMD, le conteneur ne ferait rien.

Pour aller plus loin

CMD peut être remplacé

Par exemple :

docker run mon-image echo "Hello"

Ici :

• CMD est ignoré
• la commande echo "Hello" est exécutée

CMD est une valeur par défaut.

Le système de couches (layers)

Chaque RUN ajoute une couche à votre image.

Par exemple :

RUN apt-get update
RUN apt-get install -y curl

Crée deux couches.

Les différentes couches sont utilisées par Docker pour optimiser la mémoire utilisée par les images, car les couches similaires sont partagées entre les différents conteneurs !

Résumé de l'article

RUN et CMD sont complémentaires.

• utilisez RUN pour construire votre environnement (exécuté pendant le build)
• utilisez CMD pour lancer votre application (exécuté au runtime)

Si vous les confondez, votre conteneur ne fera probablement pas ce que vous attendez.

un git reset.

Vous revenez en arrière, vous changez d’état, vous annulez un commit ou vous bougez votre branche… et là, en regardant votre projet, vous vous retrouvez avec plein de fichiers qui traînent.

Parfois ce sont :

• des fichiers générés
• des dossiers de build
• des fichiers temporaires
• des morceaux d’un ancien état du projet

Et dans git status, vous voyez apparaître une longue liste de fichiers “nouveaux”.

Git ne les a pas supprimés, parce qu’ils ne font pas partie des fichiers suivis à cet instant. Mais si vous souhaitez vous en débarasser (autrement qu’en supprimant tout à la main), voilà comment faire !

La bonne commande : git clean

Pour supprimer les fichiers non suivis, Git propose cette commande :

git clean -f

Cette commande supprime les fichiers non suivis du dossier courant.

Mais attention :

git clean est une commande destructive.

Une fois les fichiers supprimés, Git ne pourra pas les restaurer.

Le mode simulation

Avant de lancer une suppression, le bon réflexe est d’utiliser :

git clean -n

Le -n signifie dry run. C’est probablement l’option la plus importante de toute la commande.

Git affiche ce qu’il supprimerait, sans réellement le faire. Si vous avez beaucoup de fichiers apparus après un git reset, commencez toujours par là.

Supprimer les dossiers

Par défaut, git clean ne supprime pas les dossiers non suivis.

Or après un reset, ce sont souvent justement des dossiers entiers qui traînent :

• dist/
• build/
• .cache/
• anciens dossiers générés

Pour inclure les dossiers, utilisez :

git clean -fd

• f pour forcer
• d pour inclure les répertoires

Dans beaucoup de cas, après un git reset, c’est cette commande qu’on cherche vraiment.

Inclure les fichiers ignorés par .gitignore

Il y a un autre cas fréquent.

Vous faites un reset, puis vous voulez repartir d’un projet vraiment propre.

Mais certains fichiers sont ignorés par Git via .gitignore :

• dossiers de build
• fichiers d’environnement
• caches
• dépendances générées

Par défaut, git clean ne les supprime pas.

Si vous voulez aussi supprimer ces fichiers ignorés, il faut utiliser :

git clean -fdx

Cette commande supprime :

• les fichiers non suivis
• les dossiers non suivis
• les fichiers ignorés par .gitignore

Elle est très utile pour remettre un projet dans un état vraiment propre.

Mais elle doit être utilisée avec une grande prudence.

Supprimer UNIQUEMENT les fichiers ignorés

Pour ne supprimer que les fichiers présents dans .gitignore ,on utilise le paramètre -X (à ne pas confondre avec -x) :

git clean -fdX

Supprime uniquement les fichiers ignorés

Conclusion

Retenez surtout ceci :

• git clean -n permet de vérifier avant
• git clean -fd supprime fichiers + dossiers
• git clean -fdx fait le ménage complet

npm install

Cette commande semble anodine. Elle télécharge simplement les dépendances listées dans le package.json.

Mais en réalité, npm peut aussi exécuter du code pendant l’installation.

Beaucoup de développeurs l’ignorent, mais certains packages contiennent des scripts qui s’exécutent automatiquement lors de l’installation. Et dans certains cas, ces scripts peuvent poser problème : comportements inattendus, téléchargements lourds… ou pire, scripts malveillants.

Heureusement, npm propose une option simple pour éviter cela :

npm install --ignore-scripts

Cette option empêche npm d’exécuter les scripts définis dans les dépendances.

Les scripts exécutés automatiquement par npm

Dans un package.json, un package peut définir plusieurs scripts.

Par exemple :

{
  "scripts": {
    "postinstall": "node build.js"
  }
}

npm peut exécuter automatiquement certains scripts pendant l’installation.

Les plus courants sont :

• preinstall
• install
• postinstall
• prepare

Ces scripts sont souvent utilisés pour compiler du code natif, télécharger des binaires, générer des fichiers nécessaires au package, préparer des assets, etc…

Le problème, c’est que npm exécute ces scripts automatiquement, sans vous demander votre avis.

Le risque : exécuter du code sans le savoir

L’écosystème npm est immense. On compte aujourd’hui plus de deux millions de packages.

Et comme dans tout écosystème ouvert, il arrive que certains packages soient malveillants ou compromis.

Plusieurs incidents ont déjà eu lieu :

• des packages abandonnés repris par des acteurs malveillants
• des dépendances injectant du code espion
• des scripts envoyant des informations système

Les scripts postinstall sont particulièrement sensibles, car ils s’exécutent directement sur votre machine au moment de l’installation.

Concrètement, un script npm peut :

• accéder à votre système de fichiers
• lire des variables d’environnement
• envoyer des données vers Internet
• modifier votre configuration

En d’autres termes : un simple npm install peut exécuter du code arbitraire.

Utiliser ignore-scripts pour garder le contrôle

Pour éviter cela, npm propose une option très simple :

npm install --ignore-scripts

Avec cette commande :

• npm télécharge les dépendances
• npm les installe dans node_modules
• mais aucun script n’est exécuté

Cela bloque :

• preinstall
• install
• postinstall
• prepare

Les packages sont installés sans exécution de code externe.

⚠️ Attention : --ignore-scripts bloque absolument tous les scripts.

Il n’est pas possible de désactiver uniquement postinstall ou un script spécifique.

Si vous utilisez cette option, aucun script lifecycle ne sera exécuté, quel que soit le package.

Cette option est particulièrement utile dans plusieurs situations :

• audit de dépendances
• analyse d’un projet inconnu
• environnement sécurisé
• pipeline CI/CD
• installation de dépendances non fiables

Équivalent avec pnpm et yarn

Si vous utilisez un autre gestionnaire de paquets, sachez que des options similaires existent.

pnpm

pnpm propose exactement la même option :

pnpm install --ignore-scripts

Le comportement est identique à npm : les dépendances sont installées mais aucun script lifecycle n’est exécuté.

Yarn

Avec Yarn (v1 ou v3), l’option est également disponible :

yarn install --ignore-scripts

Comme pour npm et pnpm, cela bloque l’exécution des scripts preinstall, install et postinstall.

Autrement dit, les trois principaux gestionnaires de paquets Node.js offrent ce mécanisme de sécurité.

Réactiver les scripts si nécessaire

Si un package a réellement besoin de ses scripts pour fonctionner, vous pouvez les relancer plus tard.

Par exemple :

npm rebuild

Ou simplement relancer l’installation normalement :

npm install

L’avantage est que vous gardez le contrôle sur ce qui s’exécute sur votre machine.

Dans un écosystème aussi vaste que npm, cette petite option peut éviter de nombreux problèmes.

Si votre serveur attend que le zip soit compressé puis envoyé avant de répondre à l’utilisateur :

• la requête devient lente
• votre serveur peut bloquer
• la requête peut échouer à cause d’un timeout

La solution consiste à déléguer ce travail à un système de tâches asynchrones.

Au lieu de créer le zip directement, l’application ajoute une tâche dans une file :

(1) Exporter données (user@example.com) -- En cours...
(2) Exporter données (user2@test.com)   -- En attente
(3) Exporter données (user3@fake.com)   -- Tâche ajoutée

L’utilisateur, lui, va recevoir une confirmation immédiate du traitement de sa demande, et un autre processus (parfois un autre serveur, conteneur,…) se chargera de traiter la demande et d’envoyer l’email.

Comme ceci :

Lire la tâche en cours
|
Récupérer les données
|
Créer l'archive zip
|
Envoyer l'email (user@example.com)
|
Valider la tâche

Tant qu’il y a des tâches en cours, le processus les traitera les unes à la suite des autres, dans l’ordre d’arrivée (First In - First Out ou FIFO)

De cette manière, notre serveur web n’est pas bloqué par des tâches longues ou coûteuses, il peut continuer à traiter le reste de ses requêtes facilement !

Qu’est-ce que BullMQ ?

BullMQ est une bibliothèque permettant de gérer ce type de file de tâches.

Elle repose sur Redis, une base de données en mémoire très rapide qui sert à stocker et coordonner les tâches.

Si vous ne connaissez pas Redis, on vous a préparé un article dédié !

Le fonctionnement repose sur trois éléments :

• La queue (file) : l’endroit où les tâches sont ajoutées
• Les workers : des processus qui exécutent les tâches
• Redis : le moteur qui stocke les jobs et leur état

Le flux ressemble généralement à ceci :

1. L’application ajoute une tâche dans la queue
2. Redis stocke cette tâche
3. Un worker récupère la tâche
4. Le worker exécute l’action (ex : envoyer un email)

Ce modèle permet de séparer la logique métier principale des traitements lourds.

Attention, BullMQ n’est pas un MessageBroker, c’est simplement une file d’attente ! On va voir la différence un peu plus loin avec RabbitMQ par exemple.

Un exemple simple

Voici un exemple minimal avec Node.js pour ajouter une tâche dans une queue :

import { Queue } from "bullmq";

const emailQueue = new Queue("email-queue", {
  connection: {
    host: "localhost",
    port: 6379
  }
});

await emailQueue.add("send-welcome-email", {
  email: "user@example.com",
  name: "Alice"
});

Ce code ajoute une tâche appelée send-welcome-email dans Redis.

Et voici un exemple d’un Worker qui traite les tâches :

import { Worker } from "bullmq";

const worker = new Worker(
  "email-queue",
  async job => {
    const { email, name } = job.data;

    console.log(`Envoi de l'email de bienvenue à ${name} (${email})`);

    // Ici on pourrait appeler un service SMTP
    // sendEmail(email, ...)
  },
  {
    connection: {
      host: "localhost",
      port: 6379
    }
  }
);

Dès qu’une tâche est ajoutée, le worker la récupère et exécute le traitement.

Cas d’usage typiques

Les files de tâches comme BullMQ sont utilisées pour :

• envoyer des emails
• générer des rapports ou documents
• traiter des images ou vidéos
• importer de grandes quantités de données
• exécuter des tâches planifiées
• lancer des traitements lourds en arrière-plan

Dès qu’une opération peut prendre du temps ou échouer temporairement, une queue devient utile.

Les forces et faiblesses de BullMQ

BullMQ présente plusieurs avantages importants : il est performant, gèrent les “retries” en cas d’échecs, mais possède surtout une très bonne DX et n’a besoin que d’une dépendance d’infrastructure (Une base Redis).

Mais cela reste néanmoins une solution relativement simple, avec ses limites : limité à NodeJS, Python et PHP, il est également mois adapté aux architectures très distribuées.

Et RabbitMQ alors ?

La différence principale entre BullMQ et RabbitMQ est leur rôle :

• BullMQ est une bibliothèque de gestion de tâches.
• RabbitMQ est un message broker, conçu pour faire communiquer plusieurs services entre eux.

Avec RabbitMQ, chaque service peut envoyer des messages sur la Queue, et chaque service est libre de traiter un message comme il l’entend. BullMQ permet simplement d’envoyer une tâche de manière unilatérale, et avec une seule source de vérité (même si autant de Worker peuvent écouter les tâches).

RabbitMQ est aussi plus lourd à mettre en place, avec une infrastructure dédiée, et son protocol basé sur AMQP.

Note supplémentaire

Il est important de rappeler que BullMQ est capable de garder les tâches en mémoire à long terme, uniquement si la persistence est activée sur votre base de données Redis !

Une variable d’environnement est une valeur stockée par le système d’exploitation et accessible par les programmes.

Elles servent à définir le contexte d’exécution d’une application :

• nom du serveur
• chemin vers une base de données
• mode de fonctionnement (DEV / PROD)
• etc...

En COBOL, on peut y accéder grâce à l’instruction ACCEPT.

Lire une variable d’environnement en COBOL

Voici un exemple simple pour récupérer la variable d’environnement APP_MODE :

       IDENTIFICATION DIVISION.
       PROGRAM-ID. EnvExample.

       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01  APP-MODE       PIC X(10).

       PROCEDURE DIVISION.
           ACCEPT APP-MODE FROM ENVIRONMENT "APP_MODE"
           DISPLAY "Mode d'exécution : " APP-MODE
           STOP RUN.

• ACCEPT permet de lire une entrée externe.
• En précisant FROM ENVIRONMENT "APP_MODE", on demande à COBOL de lire la variable d’environnement correspondante.
• La valeur est stockée dans la variable APP-MODE.

Exemple pratique

Imaginons que vous vouliez exécuter certaines instructions selon l’environnement :

       IF APP-MODE = "DEV"
           DISPLAY "Connexion à la base de test..."
       ELSE
           DISPLAY "Connexion à la base de production..."
       END-IF.

Mais avant d’exécuter votreprogramme, tu peux définir la variable selon le contexte :

Mode d'exécution : DEV
Connexion à la base de test...

Gérer les cas particuliers

Les valeurs numériques

Une chose à retenir, c’est qu’une variable d’environnement est toujours passée à un programme sous forme de string. Il est possible de la convertir automatiquement en COBOL, en la déclarant comme une valeur valeur numérique, comme ceci avec port qui serait égal à 3000 :

01 PORT PIC 9(4).
ACCEPT PORT FROM ENVIRONMENT "PORT"

Mais ce n’est pas conseillé.

Si votre votre variable contient par erreur une valeur qui ne peut pas être parsée, alors il y a de fortes chances que votre programme crash (en fonction de votre environnement).

Il vaut mieux lire une valeur alpha-numérique, pour ensuite vérifier et convertir, comme ceci :

01 PORT-STR PIC X(10).
01 PORT     PIC 9(4).

ACCEPT PORT-STR FROM ENVIRONMENT "PORT"

IF PORT-STR IS NUMERIC
    MOVE PORT-STR TO PORT
ELSE
    DISPLAY "PORT invalide"
END-IF

Les valeurs vides

Si une variable d’environnement est lue, mais quelle est vide (ou simplement non définie), alors votre programme ne recevras qu’un ensemble d’espaces équivalent à la longueur de votre variables.

Pour vérifier si votre variable est définie ou non, et lui assigner une valeur par défaut, il vous suffira de faire ceci :

ACCEPT APP-MODE FROM ENVIRONMENT "APP_MODE"
IF APP-MODE = SPACES
    MOVE "DEV" TO APP-MODE
DISPLAY "Mode d'exécution : " APP-MODE
STOP RUN.

La constante SPACES est une constante “figurative”, qui s’adapte au contexte, et elle correspond au nombre d’espaces nécessaires pour remplir votre variable.