Décompilation

Décompilation : Reconstruction d’un code source approximatif à partir du paquet installé, qui rend visible toute logique embarquée dans l’application.

Ce terme appartient à la famille « Sécurité ». La page reprend l’essentiel : à quoi ça sert, comment l’écrire, ce qui se passe quand on l’oublie.

À quoi sert Décompilation

Décompilation relève de la sécurité applicative, un poste que les devis traitent souvent en une ligne et qui se rattrape mal une fois l’application en ligne.

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.

Comment l’écrire dans un cahier des charges

Le cahier des charges doit prévoir qui teste « Décompilation » 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 :

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

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.

Pour le cadre général, le guide des prix donne les fourchettes constatées en France et le modèle de cahier des charges la structure qui les rend opposables.

Vérifier plutôt que croire

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

• Contrôler qu’aucun secret ne traîne dans le code livré.
• Passer en revue la liste des personnes ayant accès à la production.
• S’assurer que les journaux ne contiennent aucune donnée personnelle.

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

Erreurs fréquentes

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 :

• Réponse à incident
• Départ d’un collaborateur
• Appareil perdu ou volé
• Divulgation responsable
• Effacement à distance

Questions fréquentes

Qu’est-ce que « Décompilation » ?

Reconstruction d’un code source approximatif à partir du paquet installé, qui rend visible toute logique embarquée dans l’application. La définition tient en une phrase, son application dépend du projet. C’est pour cette raison qu’elle doit figurer dans le cahier des charges plutôt que dans un échange de courriels.

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.

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.