JWT

JWT : Format de jeton signé transportant des attributs d’identité, dont la signature doit être vérifiée côté serveur à chaque appel reçu.

Entrée de la famille « Sécurité » du glossaire. Elle s’adresse à un porteur de projet qui doit rédiger, comparer ou recetter, pas à un spécialiste du sujet.

À quoi sert JWT

JWT protège les données confiées par les utilisateurs. Sur mobile, la question se pose deux fois : sur le téléphone, qui peut être perdu ou compromis, et sur le serveur.

Dans la pratique, deux interlocuteurs qui n’ont pas la même définition en tête avancent d’accord pendant des semaines, puis découvrent le désaccord à la livraison.

La traduction en exigences

Écrire « JWT » dans un cahier des charges engage un travail réel, pas une case à cocher : configuration, code, procédure, et preuve à produire.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Les modalités d’authentification, second facteur compris s’il est requis.
• Le stockage des secrets, côté application comme côté serveur.
• La gestion des accès de production, et leur revue périodique.
• Le test de restauration des sauvegardes, réellement exécuté au moins une fois.

Reste à désigner qui écrit cette ligne et qui la valide. Sans nom en face, la rubrique se remplit la veille de la signature, avec les mots du prestataire.

Le modèle de cahier des charges du guide reprend ces rubriques dans l’ordre attendu par une agence, et la grille de lecture des devis montre à quoi ressemble un chiffrage comparable.

Les contrôles à prévoir

À la recette, JWT se contrôle sur pièces : configuration, journaux, preuve de test. Pas sur une déclaration de bonne intention.

• Passer en revue la liste des personnes ayant accès à la production.
• S’assurer que les journaux ne contiennent aucune donnée personnelle.
• Réclamer la preuve d’un test de restauration de sauvegarde.

Ce qui n’est pas vérifié à la recette ne sera pas vérifié du tout : le jour de la mise en ligne, plus personne n’a le temps.

Les pièges à éviter

Ces erreurs ne viennent presque jamais d’un manque de compétence, mais d’un point qui n’a été écrit nulle part.

• Traiter la sécurité en fin de projet, quand tout est déjà recetté.
• Stocker un secret dans le code de l’application, où il est lisible par qui veut le lire.
• Commander un audit sans budgéter les corrections qu’il va produire.
• Laisser les accès de production ouverts à d’anciens intervenants.
• Repousser l’arbitrage au sprint suivant, autant de fois qu’il y a de sprints.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• Valorisation
• Conformité continue
• EBIOS Risk Manager
• Gestionnaire de mots de passe
• Tableau de bord sécurité

Questions fréquentes

JWT : de quoi parle-t-on exactement ?

Format de jeton signé transportant des attributs d’identité, dont la signature doit être vérifiée côté serveur à chaque appel reçu. Cette définition suffit pour une discussion de cadrage. Pour un contrat, il faut y ajouter ce que le terme recouvre exactement sur votre application.

Faut-il un audit de sécurité sur toutes les applications ?

Pas au même niveau. Une application sans compte ni donnée personnelle n’appelle pas l’effort d’un service bancaire. Le classement des données manipulées donne la mesure du travail à prévoir.

Où placer ce point dans le cahier des charges ?

Dans le chapitre qui correspond à sa nature, jamais dans une ligne fourre-tout. Le modèle de cahier des charges propose les rubriques attendues et l’ordre dans lequel les remplir.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.