• é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.

Tout semble équivalent. En réalité, derrière ces termes se cachent des significations bien différentes.

Alors on vous a préparé un guide pour éclaircir tout ça !

Les diplôme d’Etat

Un diplôme d’État est délivré par une université ou un établissement habilité par l’État (comme une école d’ingénieur). Il s’inscrit dans le système LMD (Licence - Master - Doctorat) et donne des crédits ECTS reconnus en Europe.

Exemples :

• BUT Informatique (anciennement DUT)
• Licence Informatique
• Master Informatique
• Diplôme d’ingénieur (Bac +5 réservé aux écoles d’ingénieurs)

Ces formations offrent généralement une base théorique solide : algorithmique, systèmes, structures de données, parfois mathématiques avancées.

Elles sont particulièrement adaptées si vous souhaitez :

• Continuer vers un Bac+5 ou un doctorat
• Garder une reconnaissance académique forte
• Travailler à l’international

En revanche, elles peuvent être plus longues et parfois moins professionalisantes.

Les titres professionnels (RNCP)

Un titre RNCP (Répertoire National des Certifications Professionnelles) est une certification professionnelle reconnue par l’État.

Il ne s’agit pas d’un diplôme universitaire, mais d’une validation de compétences liées à un métier précis.

Chaque titre possède un niveau (5 = Bac+2, 6 = Bac+3/4, 7 = Bac+5) et un référentiel de compétences.

Pour un développeur, vous verrez souvent des titres comme :

• Développeur web et web mobile (niveau 5)
• Concepteur développeur d’applications (niveau 6)
• Expert en ingénierie logicielle (niveau 7)

Il en existe d’autres, et elles peuvent changer en fonction des années mais celles-ci sont les plus courantes

Ces formations reconnues par l’état sont généralement plus professionnalisantes, avec beaucoup de projets concrets et souvent de l’alternance.

Mais elles vous forment également à la réalité d’un métier à un instant T, sans toujours apporter les bases les plus solides pour s’adapter à de futurs changement, contrairement à la voie universitaire.

Bachelor et Mastère : des termes marketing

En France, les mots “Bachelor” et “Mastère” ne sont pas protégés.

Cela signifie qu’une école peut appeler sa formation “Bachelor Développeur Web” sans que cela corresponde à un diplôme d’État.

Ce qui compte réellement, ce n’est pas le nom, mais :

• Existe-t-il un titre RNCP associé ?
• À quel niveau est-il enregistré ?

Un Bachelor ou un Mastère peut être très sérieux… ou simplement marketing. Il faut toujours faire attention.

Vous aurez noté la différence entre un “Master” (universitaire) et un “Mastère” (non-reconnu par l’état), beaucoup de personnes confondent les deux chaque année.

Les certifications

Une certification n’est ni un diplôme ni un titre RNCP.

Il s’agit d’une validation ciblée de compétences, par exemple :

• Certification React
• Certification AWS
• Certification Scrum

Ces certifications peuvent valoriser un profil, mais elles ne remplacent pas une formation complète.

Trouvez votre future école

La réalité du marché d'aujourd'hui fait que ce n'est pas simplement le diplôme qui fera de vous un.e professionnel.le, mais surtout la qualité des apprentissages, des cours et des projets dispensés à l'école qui pourront vous donner une longueur d'avance.

C'est pour cela qu'on a lancé notre référentiel national des écoles d'informatique en France, pour que chaque étudiant.e puisse laisser un ou plusieurs avis pour guider les futurs étudiants !

Découvrez notre référentiel complet

Dans cet article, nous allons voir comment générer des PDFs à partir d’un template HTML de la manière la plus simple possible avec SecretPDF.

Pourquoi générer des PDFs est souvent complexe ?

Le format PDF est à la fois simple et complexe. Il est simple d’utilisation, car portable (il inclut toutes les ressources nécessaire pour le rendu), mais il est complexe à produire.

Un PDF peut contenir du texte, des polices d’écriture, des images, du vectoriel, etc…

Il est possible de générer un fichier PDF directement depuis le navigateur, mais dès que l’on a besoin d’un rendu légèrement complexe (autrement dit “joli”), c’est un casse-tête, surtout sur mobile.

Si votre objectif est de :

• Générer un vrai document
• Avec un design intéressant
• Du contenu texte sélectionnable (pas seulement une image)
• Sans hack CSS obscur

Alors vous devez générer des PDF côté serveur, ce qui implique de trouver la solution qui convient à vos contrainte, monter une architecture, la dimensionner, faire en sorte que cela n’impacte pas les performances de vos autres applications.

C’est là qu’arrive SecretPDF !

::: image :::

SecretPDF, c’est quoi ?

SecretPDF est un SaaS facile d’utilisation, avec une API moderne pour générer des documents PDF à partir de HTML.

Vous lui envoyez :

• du HTML/CSS (même des classes Tailwind pour le design si vous voulez)
• des données dynamiques
• un format de page

Il vous renvoie :

• un PDF prêt à télécharger

Et en plus l’outil est RGPD-compliant et neutre en carbone. Que demander de plus ?

Le tarif

SecretPDF fonctionne avec un système de crédits (1 pdf = 1 crédit pour les PDF <2Mo)

Vous avez :

• 10 crédits gratuits tous les mois
• Puis 0.01$ par crédit

C’est idéal pour les startups et les SaaS : Pas de document généré, pas de paiement.

D’ailleurs vous n’êtes même pas obligé de rentrer votre carte bancaire pour commencer.

À noter également que vous pouvez générer autant de documents de test que vous désirez, grâce à une option “sandbox” qui vous permet de tester vos templates gratuitement !

Etape 1 : Créer un compte

Pour créer un compte, il suffit de connecter son compte Github, en un seul clic !

Ensuite, vous serez guidé vers la création de votre premier template et de votre première clé d’API. L’un des gros avantages de SecretPDF est qu’il vous permet de créer vos templates directement de puis l’interface (avec une preview) ou bien depuis l’API :

::: image :::

Étape 2 : Installer le client

Vous pouvez utiliser l’API avec n’importe quel langage ou framework en suivant la documentation officielle, mais vous pouvez également utiliser le client NodeJS dédié pour vous faciliter la vie.

Dans votre projet Node.js exécutez la commande suivante :

npm install @secretpdf/sdk

Puis dans votre code, initialisez-le :

import SecretPDF from "@secretpdf/sdk";

const client = new SecretPDF({
  apiKey: "<secret>",
});

Il est évidemment conseillé de définir votre clé API dans vos variables d’environnement

Etape 3 (optionnelle) : Créer un template depuis l’API

Si vous préférez créer votre premier template directement depuis l’API, c’est possible, comme ceci :

const response = await client.createTemplate({
  name: "Facture",
  size: "A4",
  content: `
    <main class="p-10">
      <h1 class="text-3xl font-bold text-blue-600">
        Facture
      </h1>
      <p>Prestataire : {{name}} (SIRET {{siret}})</p>
      <p>Montant: {{amount}}€</p>
      <p class="mt-4 text-gray-700">
        Merci pour votre confiance.
      </p>
    </main>
  `,
});

const templateId = response.data.id;

Je vous conseille quand même d’utiliser l’interface, cela vous facilitera la vie.

Étape 4 : Générer votre premier PDF

Voici l’exemple le plus simple possible pour générer un PDF à partir de votre template :

const response = await client.generate({
  sandbox: true,
  templateId: "<template_id>",
  data: {
    name: "Nicolas Brondin-Bernard",
    siret: "784 671 695 00103",
    amount: 139.99,
    date: new Date()
  }
});

sandbox permet de générer un document de test avec un watermark par dessus, ce qui ne consommera aucun crédit.

La réponse contient une simple propriété data avec le contenu du fichier généré (encodé en Base64), c’est aussi simple que ça !

Étape 5 (optionnelle) : Sauvegarder le fichier sur disque

Rien en vous oblige à stocker le fichier généré, vous pouvez par exemple l’envoyer en réponse HTTP à votre utilisateur, mais si vous souhaitez le faire, rien de plus simple :

import fs from "fs";

const response = await client.generate({
  //...
});

const pdfBuffer = Buffer.from(result.content, 'base64');
fs.writeFileSync('output.pdf', pdfBuffer);

Et voilà, le tour est joué !