Discussion :

[Gestion-RH]

Bonjour
depuis plus de 2 ans (environs 300 heures) je construit un outil d'organisation du temps de travail.
les onglets et les codes VBA sont protégés par mots de passe (un premier pour les onglets utilisateurs, un second pour les onglets administrateurs et enfin un troisième pour accéder aux codes VBA).
Sur un autre outil, j'avais perdu le mot de passe. Après quelques recherches je suis tombé sur cet article https://www.futura-sciences.com/tech...t-passe-12712/.
La méthode est effectivement fonctionnelle ... et c'est bien ce qui m'embête car je ne souhaites pas que mon outil puisse être déprotégé (particulièrement l'accès aux codes).
Mon outil possède bien un code qui restaure toutes les protections des onglets à l'ouverture mais rien ne consolide l'accès aux codes.
Avez-vous une opinion, une expérience ou une solution sur une protection perenne ?
En vous remerciant par avance.
Bonne journée

[Nain porte koi]

Hello,

à partir du moment ou qqchose est "protégé", informatiquement parlant, la question n'est pas "est-ce que la protection est efficace ?" mais "quand sera t'elle crackée ?"
A mon sens il n'existe aucun moyen d'empêcher une sécurité de sauter à un moment ou à un autre, tout est question de moyen et d'intérêt.

A la rigueur vous pourriez mettre vos macros dans un fichier .xlam qui est compilé, mais ça va vous obligez à revoir intégralement votre code et ça va alourdir l'installation car il faudra charger le complément (.xlam) avant d'utiliser votre outils d'organisation du temps de travail.
Est-ce que le jeu en vaut vraiment la chandelle ??? Quel est le risque si une personne cracke votre appli ?

[Gestion-RH]

Bonjour
Merci pour votre réponse.
"Quel est le risque si une personne cracke votre appli ?". En fait il n'y en a pas vraiment, c'est juste une question de paternité
Finalement vos arguments sont plus éclairés que les miens. Je pense que j'ai fait de mon mieux ... et advienne que pourra.
Merci beaucoup.
Bonne journée

[Philippe Tulliez]

Bonjour,

Malheureusement, il faut partir du principe que les protections Excel ne sont pas des mécanismes de sécurité robustes, mais surtout des protections “de confort” destinées à éviter les manipulations accidentelles.

Cela fait effectivement très longtemps que les protections de feuilles, de structure ou même de projet VBA peuvent être contournées relativement facilement.
Déjà il y a une vingtaine d’années, on trouvait des outils capables de supprimer les mots de passe VBA en quelques secondes.

Aujourd’hui, d’autres méthodes rendent également ces protections peu fiables :

• ouverture via LibreOffice ;
• modification directe du fichier XLSM (qui est en réalité une archive ZIP) ;
• certaines conversions cloud ;
• outils spécialisés disponibles très facilement.

Le point important est donc le suivant :

• la protection VBA empêche surtout un utilisateur “classique” d’aller modifier le code ;
• elle ne protège pas réellement une propriété intellectuelle contre quelqu’un de motivé.

Dans les projets sensibles, plusieurs approches sont souvent utilisées :

• déplacer la logique critique dans un COM Add-in ou une DLL compilée ;
• utiliser une base de données ou un service externe ;
• limiter le code VBA présent dans le classeur ;
• signer le projet VBA ;
• ou accepter qu’Excel ne soit pas une plateforme conçue pour sécuriser du code métier.

Personnellement, lorsque je développe sous Excel, je considère désormais la protection VBA davantage comme un frein psychologique que comme une vraie sécurité.

Et au final, dans beaucoup d’applications métier, ce qui rend réellement l’outil difficile à reproduire ou à maintenir, ce n’est pas le mot de passe VBA, mais plutôt :

• l’architecture globale ;
• l’organisation des données ;
• la logique métier ;
• les paramétrages ;
• et toute l’expérience accumulée au fil des évolutions du projet.

C’est souvent cette partie-là qui représente la vraie valeur du développement.

[Gestion-RH]

Bonjour
"mais surtout des protections “de confort” destinées à éviter les manipulations accidentelles" : c'est effectivement l'objectif originel ... mais quand on passe beaucoup de temps sur un projet et que l'on est fier du résultat le lien avec le projet se modifie quelque peu.
Mais comme vous et Nain porte koi l'argumentez parfaitement, il est peu utile de construire un Fort Knox pour un classeur Excel.
Dans tous les cas, un grand merci pour vos interventions.
Cordialement

[Victor21]

Bonjour.
Avez-vous songé à l'obfuscation de votre code ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

https://talks.freelancerepublik.com/obfuscation-code-sou/