Tableau de bord sécurité

Tableau de bord sécurité : Vue synthétique des indicateurs suivis, vulnérabilités ouvertes, délais de correction et couverture des tests réalisés.

Le mot appartient à la famille « Sécurité » du lexique. Cette page dit ce qu’il recouvre, comment il se formule dans un cahier des charges, et ce qu’il vaut mieux ne pas écrire.

Pourquoi Tableau de bord sécurité compte sur un projet mobile

Tableau de bord sécurité 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.

Sur un projet réel, la question ne se pose jamais en théorie : elle arrive dans un devis, dans une réunion de cadrage ou dans un rapport de recette.

Ce que ça devient dans un cahier des charges

Un cahier des charges sérieux relie « Tableau de bord 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

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

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

Erreurs fréquentes

Sur ce point précis, voici ce qui coûte le plus cher aux porteurs de projet, dans l’ordre où on le rencontre.

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

• Conformité continue
• EBIOS Risk Manager
• Gestionnaire de mots de passe

Questions fréquentes

Tableau de bord sécurité : de quoi parle-t-on exactement ?

Vue synthétique des indicateurs suivis, vulnérabilités ouvertes, délais de correction et couverture des tests réalisés. 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.

À quel moment traiter le sujet ?

Dès la conception, puis en contrôle avant la mise en ligne. Une faille corrigée sur plan coûte une discussion ; la même faille corrigée après le lancement coûte un correctif, une republication et parfois une notification.

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.