Je ne suis pas développeur, c’est un métier que je n’ai pas appris et bien que connaissant certains langages, je ne me lancerais pas dans l’écriture d’autre chose que de petits scripts.
Mais je gère des parcs de PC, et la je dois dire que parfois certains développeurs me font souffrir ou hurler !!
Alors voici 12 choses à ne jamais faire pour un développeur, suivi d’explications :
- Je ne fournis pas de programme d’installation, il suffit de copier les fichiers
- Pour fonctionner correctement mon programme à besoin de tel composant, mais je ne vous dit pas ou le trouver (google est votre ami…)
- Si vous voulez que mon programme fonctionne bien vous devez être administrateur
- Mon programme n’utilise pas le registre, les fichiers ini, c’est mieux
- Sans vous le dire, mon programme modifie des DLL de Windows, mais c’est sans conséquences
- J’ai glissé un add on qui est une beta avec mon programme, mais ça marche
- Mon programme ne fonctionne que avec une version d’Internet Explorer, ou Adobe Reader ou Word
- Mon programme utilise un dongle pour éviter le piratage ou mon programme nécessite une activation, et n’en supporte qu’une seule
- Mon programme doit s’installer à la racine, pas dans Programmes Files (ou en tous cas le fait par défaut)
- Mon programme enregistre des données dans le répertoire ou il est installé, c’est plus simple
- Mon programme a été traduit en Français par un sous traitant, mot, pour mot, ça suffit…
- Mon programme est fourni sans fichier ADMX ou possibilité de stratégie, pas besoin
Il y en a surement d’autres, je fais confiance aux développeurs en la matière, ces développeurs à qui j’aurais envie de dire : avant d’écrire un programme pour Windows, apprenez le fonctionnement de Windows et les best practice qui vont avec (au lieu de dire, Windows c’est plein de bugs… Linux c’est mieux… trop souvent entendu).
Voici quelques explications :
1 – Importance d’un programme d’installation
Non, un programme d’installation ne se contente pas de copier les fichiers dans le bon répertoire :
- il place les fichiers dans le bon répertoire, avec les bons droits
- il enregistre les DLL dans le système
- il rends le programme visible dans Ajout Suppression de programmes (sinon comment savoir quel PC contient quel logiciel ?)
- il provoque les bonnes élévations de privilège pour que tout cela fonctionne
- il fournit un fichier log, en cas de problèmes
- il fait surement encore d’autres choses que j’ignore
- et il réalise le tout : toujours de la même manière, reproductible et fiable
2 – Votre programme nécessite des pré requis, identifiez les !!
J’ai passé tellement de temps à chercher tel ou tel version de .NET (jamais la même), ou de runtime, rien de plus énervant, pourquoi ne pas fournir un lien vers une page référençant les sources pour ces add-ons ?
3 – Le danger de l’utilisateur administrateur
Le complexe d’infériorité ! Aucun programme ne doit avoir besoin de privilège élevés pour fonctionner, cela est trop dangereux !
Microsoft a dépensé des millions de dollars pour sécuriser Windows, il y a des (bonnes) raisons : éviter les risques d’infection du système, les erreurs utilisateurs, les application malveillantes, protéger votre système et vos données. Ne gâchez pas tout en décrédibilisant votre application…
4 – Découverte de la base de registre
Si vous êtes développeur pour Windows et que vous ne connaissez pas le registre, passez votre tour…
Le registre est à la fois génial et horrible, flexible et rigide, fiable et capricieux. En fait c’est un super outil qui permet à plusieurs utilisateurs de coexister sur un même PC, à votre application d’être utilisée sur de nombreux systèmes différents, aux utilisateurs de changer de PC aisément, en gros d’utiliser Windows comme il a été prévu.
Par contre mal utilisé, maintenu ou mis à mal par des applications tordues, le registre peut vite devenir un problème.
Microsoft à inventé le Registre avec Windows 3, il a été énormément amélioré, reste surement perfectible mais à vraiment fait ses preuves et lorsque vous en avez compris le fonctionnement, vous serez un expert de Windows.
Lisez cette page, vous en saurez déjà pas mal : http://www.toutwindows.com/vista_registre.shtml
5 – A quoi sert une DLL ?
Je ne suis pas développeur, mais le principe est simple : une DLL offre des fonctions (du code) qui peut être être appelé par un programme. Et pour rendre les choses plus modulables il est souvent plus aisé d’externaliser certaines fonction d’un programme (les enlever du fichier .EXE ) et de les mettre dans une DLL (ou tout autre fichier partagé). L’autre avantage d’une DLL est que les fonctions de celle-ci peuvent être utilisées par plusieurs programmes.
Nous y sommes !! Voila le cœur du problème !
Microsoft fournit un service dans une DLL v1.0, puis v1.1, 1.2 etc etc. L’auteur d’un programme à besoin de la v1.2, alors que fait il ? Il copie bêtement la nouvelle version dans un répertoire partagé de Windows (system32, par exemple).
Tout ceci vous parait logique mais ce n’est pas si simple : si entre temps une mise à jour à déjà installé la v1.3 ou la v2, alors patatras tout s’écroule.
Autre variante, au lieu de vérifier et éventuellement mettre à jour la DLL v1.2 est copié dans le même répertoire que le programme, qui pourra alors l’appeler ! Sauf si au même moment un autre programme a déjà rechargé cette DLL en mémoire, re patatras !
Rassurez vous cependant Microsoft déploie des modèles d’ingéniosité pour que tout ceci n’aboutisse pas à un désastre, surtout si ces opérations sont effectuées par un programme d’installation… (cf point 1).
6 – Une beta c’est quoi ?
Les éditeurs, Microsoft en tête, rendent de plus en plus disponible les versions beta de leur programme, cela m’attriste beaucoup !
Alors, qu’est ce qu’une beta :
Un “brouillon” de programme, une version préliminaire.
Une beta ne doit pas être installé sans compétences techniques car une fois installée, elle pourra (je dirais presque devra) nécessiter la réinstallation du Windows l’hébergeant. Elle peut aussi engendrer des plantages, des pertes de données, des problèmes de sécurité, etc etc
Donc amis développeurs, fournisseurs, éditeurs ne fournissez jamais une beta avec vos produits, encore moins sans le dire, cela révèle de l’amateurisme et de la malhonnêteté.
beta = test = plantages = rien à faire sur un PC de production ou contenant des données
Cliquez sur le lien ci-dessous pour la suite :
7 – Un système d’exploitation figé ça n’existe pas !
Si vous me suivez depuis le début de l’article, vous devez déjà l’avoir compris : un système d’exploitation comme Windows (et les autres aussi) figé cela n’existe pas !
- Il y a les mises à jour de sécurité (qui vont parfois bloquer les programmes qui ne sont pas bien écris, car ils utilisaient des fonction mal ou pas documentées, ou obsolètes).
- Il y a les nouvelles fonctionnalités qui induisent des changement.
- Il y a les nouvelles versions de programmes ou accessoires qui rendent difficile de prédire le comportement
d’un programme qui cherche par exemple à ouvrir un fichier PDF, Word, ou htm car on ne peut présager du programme et de sa version associés à l’ouverture du fichier (pour en savoir plus sur le sujet, lisez ceci : http://www.toutwindows.com/vista_registre_key.shtml )
8 – Pourquoi un dongle ? une activation ?
Souvent lorsqu’un programme est cher, l’éditeur croit bon de le protéger contre la copie. Avec un dongle (en général une espèce de clef USB cryptée), ou avec une procédure d’activation en ligne ou par téléphone ou mail.
Les inconvénients sont multiples :
Les dongles empêchent la virtualisation, multiplient les risques de perte et de panne. Je connais même des éditeurs qui vous proposent de payer plus cher si vous souhaitez supprimer le dongle pour virtualiser leur application…
Les activations créent des contraintes assez fortes, surtout si elles sont limitées en nombre : l’éditeur vous demande de désinstaller l’application sur le PC1 avant de l’installer sur le PC2, d’accord mais en cas de panne ou plantage ?
En résumé, certains programmes chers sont en plus complexes à gérer et installer.. plus c’est cher, plus c’est c….. !
9 – Intérêt du répertoire Programmes (Programme Files) ?
Le répertoire par défaut pour installer les programmes est “Program Files” , mais ce répertoire n’est pas figé, il est désigné par une variable d’environnement nommée %ProgramFiles%.
- Si vous installez une application 32 bits dans un système 32 bits c’est le répertoire par défaut.
- Si vous installez une application 64 bits dans un système 64 bits c’est le répertoire par défaut.
- Si vous installez une application 32 bits dans un système 64 bits, alors le répertoire par défaut est Program Files (x86), désigné par une variable d’environnement nommée %ProgramFiles (x86)%.
Consultez ces variables avant d’installez un programme, suggérez le bon répertoire, et permettez éventuellement de le changer (en cas d’utilisation d’un autre lecteur pour installer les programmes.
Mais ne proposez, ou pire, n’imposez pas un répertoire situé à la racine du disque !!
Vous allez compliquer la gestion des droits et autorisations (y compris pour vous), rendre votre programme compliqué à partager ou virtualiser (Terminal Server ou RDV, App-V, UAC).
10 – Pourquoi séparer les données et les programmes ?
On en est au B.A. BA du développement mais cela se voit encore !!
Si vous mélangez les données et programmes (cas par exemple d’une base de donnée, ou de fichiers ini) alors vous devrez donner le droit d’écriture aux utilisateurs !
Et c’est le début des problèmes : fichiers programmes effacés ou déplacés, problèmes de sécurité, impossibilité de partager le PC entre utilisateurs….
11 – La traduction, ça a un coup, mais aussi une valeur ajoutée ?
Certains Américains pensent que la traduction peut être faite par ordinateur (Microsoft, par exemple) ou alors sous traitée au plus bas cout (Microsoft, toujours) : triste erreur !
Au mieux leur programme est parfois cocasse ou ridicule, mais aussi parfois incompréhensible, trop traduit voir la figure ci jointe extraite de Windows Vista, ou même Windows était traduit dans le titre de la fenêtre.
Les conséquences peuvent être plus graves lorsque les traductions sont insultantes :
Donc ne négligez pas les traductions, qui doivent être correctes, contextuelles et aussi en liaison avec la culture de Pays, d’ailleurs Microsoft parle de Localisation, et Adobe de Mondialisation, avec un bon exemple : dans Windows 7, même les favoris de Internet Explorer et les photos de fond du bureau sont localisées, bel effort.
Hélas Microsoft et les autres utilisent souvent des sous traitants mal payés pour les traductions, et cela se voit :
- fichiers d’aide mal traduits ou pas traduits comme dans l’interface (comme dans Word ou Excel),
- traductions pas complètement correctes comme dans les produits live ou Home server : downloader = télécharger, uploader = téléchargement…
Mais je parle ce Microsoft car c’est ce que je connais mieux, mais que dire des traductions approximatives de Google, Adobe ou aussi les traductions des programmes Français en Anglais…
A coté de cela Microsoft emploie de très bon linguistes pour les outils de vérification linguistique de Word.
12 – les stratégies systèmes (GPO ou policies)
Les GPO permettent à un administrateur de définir les paramètres par défaut ou imposés pour les applications.
Hélas en dehors de Microsoft peu d’éditeurs jouent le jeu, et même chez Microsoft certains programmes en auraient bien besoin mais n’en n’ont pas…
Pour tant il est facile pour un éditeur de réfléchir aux paramètres qu’un gestionnaire de parc souhaiterais gérer et de prévoir les clefs de registre et de faire le fichier ADMX de gestion.
Alors ajoutez de la valeur à vos programmes, et pensez GPO !
- Conclusion
Je dois vous avouer ce qui m’a décidé à écrire cet article : j’ai rencontré un éditeur qui était vraiment très loin de tout cela, et a qui j’ai promis d’écrire un article.
Mais en fait ces pages ne sont pas seulement destinées aux développeurs, mais aussi aux administrateurs qui oublient aussi ces “best practice”.
Elles sont idéalistes, mais révélatrices de la qualité d’un programme à mes yeux.
J’aurais aussi pu en ajouter (gestion des numéro de versions, des mises à jour, ergonomie, boites de dialogue, messages d’erreur, assistance) mais ce sera sans doute pour un prochain article…
Editeurs, à votre disposition pour des explications plus détaillez, n’hésitez pas à me contacter…
Laurent Gébeau