Critère d’acceptation sécurité

Critère d’acceptation sécurité : Condition vérifiable qu’une fonctionnalité doit remplir avant d’être considérée comme livrée par l’équipe.

Classé dans la famille « Sécurité », ce terme revient dans les échanges entre un client et son agence. Voici ce qu’il faut en comprendre avant d’en discuter le prix.

À quoi sert Critère d’acceptation sécurité

Critère d’acceptation sécurité figure dans les référentiels utilisés par les auditeurs. Un client grand compte le vérifiera avant de signer, un prestataire sérieux l’a déjà prévu.

Le sujet mérite trois minutes d’attention au cadrage. C’est le seul moment du projet où il ne coûte rien à traiter.

La traduction en exigences

Un cahier des charges sérieux relie « Critère d’acceptation sécurité » aux données concernées. Toutes ne méritent pas le même niveau de protection, et tout protéger au maximum coûte cher sans rien garantir de plus.

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

Rien n’oblige à tout figer dès le premier jour. Ce qui reste ouvert doit alors être signalé comme tel, avec la date à laquelle la décision sera prise.

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.

Vérifier plutôt que croire

Critère d’acceptation sécurité se vérifie par un tiers, avec un rapport écrit et une liste de corrections datées.

• Demander le rapport d’audit complet, pas la seule page de synthèse.
• Vérifier que les correctifs annoncés ont été retestés, et par qui.
• Observer le comportement de l’application avec un jeton expiré.

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

Les pièges à éviter

Les mêmes causes reviennent d’un projet à l’autre, quel que soit le prestataire et quelle que soit la taille du budget.

• 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.
• Confier la décision au prestataire, puis la contester au moment de la recette.

Termes liés

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

• Boîte grise
• Conformité continue
• EBIOS Risk Manager
• Gestionnaire de mots de passe
• Tableau de bord sécurité

Questions fréquentes

Que signifie « Critère d’acceptation sécurité » ?

Condition vérifiable qu’une fonctionnalité doit remplir avant d’être considérée comme livrée par l’équipe. 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.

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.