Permission d’exécution

Permission d’exécution : Autorisation demandée au moment de l’usage, à justifier par un message clair pour éviter un refus définitif.

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 Permission d’exécution

Sur un projet d’application, Permission d’exécution se traite pendant la conception. Ajouter la sécurité à la fin revient à réécrire des parties déjà recettées, donc à les recetter de nouveau.

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

Le cahier des charges doit prévoir qui teste « Permission d’exécution » et à quel moment. Une revue de sécurité programmée après la mise en ligne arrive trop tard pour changer quoi que ce soit.

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

• Le référentiel de sécurité appliqué, nommé dans le contrat.
• Le classement des données manipulées, de la plus banale à la plus sensible.
• La revue de sécurité prévue avant la mise en ligne, et qui la mène.
• La procédure de correction d’une faille signalée, avec son délai d’engagement.

Une exigence bien écrite tient en trois lignes et se refuse en une. Si elle ne peut pas être refusée à la recette, elle n’est pas encore écrite.

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.

Comment le vérifier à la recette

Permission d’exécution se recette avant la mise en ligne, puis se revérifie après les corrections. Un correctif non retesté n’est pas un correctif.

• Demander le rapport d’audit complet, pas la seule page de synthèse.
• Observer le comportement de l’application avec un jeton expiré.
• Vérifier que les contrôles d’accès sont bien refaits côté serveur.

Chacun de ces contrôles prend quelques minutes. Les découvrir après la mise en ligne prend des jours.

Les pièges à éviter

Aucune de ces erreurs ne se voit le jour où elle est commise. Toutes se paient plus tard, au moment le moins commode.

• 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 :

• Paywall dur
• Dernier clic
• Conformité continue
• EBIOS Risk Manager
• Gestionnaire de mots de passe

Questions fréquentes

Qu’est-ce que « Permission d’exécution » ?

Autorisation demandée au moment de l’usage, à justifier par un message clair pour éviter un refus définitif. Le mot est employé tel quel par les équipes francophones. C’est celui à utiliser dans les échanges avec une agence, y compris quand la traduction française existe.

Qui doit s’en charger ?

Le prestataire construit, un tiers vérifie. Faire auditer par celui qui a développé revient à faire corriger une copie par son auteur : utile, insuffisant pour un service exposé au public.

Est-ce que ça se retrouve dans le devis ?

Un devis lisible sépare conception, design, développement, tests, publication et suivi. La grille de lecture des devis détaille poste par poste ce qui doit y apparaître.

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