Homologation

Homologation : Décision formelle par laquelle un responsable accepte les risques résiduels d’un système et autorise sa mise en service effective.

Famille « Sécurité ». La définition ci-dessus suffit pour suivre une réunion. La suite sert à écrire une exigence que personne ne pourra interpréter à sa façon.

Pourquoi Homologation compte sur un projet mobile

Sur un projet d’application, Homologation 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.

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 « Homologation » 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 :

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

Cette formulation se rédige avant la consultation, pas après réception des propositions : c’est elle qui rend deux devis comparables entre eux.

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

À la recette, Homologation 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.

Un prestataire sérieux propose ces contrôles de lui-même. Quand ce n’est pas le cas, c’est au client de les inscrire au cahier de recette.

Erreurs fréquentes

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.
• Ne relier le sujet à aucun critère de recette : ce qui ne se vérifie pas ne se livre pas.

Termes liés

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

• Appel de décision
• Conformité continue
• EBIOS Risk Manager
• Gestionnaire de mots de passe
• Tableau de bord sécurité

Questions fréquentes

Homologation : de quoi parle-t-on exactement ?

Décision formelle par laquelle un responsable accepte les risques résiduels d’un système et autorise sa mise en service effective. 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.

Par où commencer quand le sujet est nouveau ?

Par les parcours et les règles de gestion, pas par les outils. Le guide du cahier des charges donne l’ordre dans lequel poser les questions à une agence.

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