Le logiciel que vous utilisez se comporte n’importe comment sans que vous ne compreniez pourquoi ? Il n’y a aucun message d’erreur, la configuration vous semble bonne, mais impossible d’obtenir le résultat attendu ?
Vous êtes peut-être victime d’un comportement par défaut !
Ce dont je vous parle ici n’est pas une « configuration par défaut », mais provient souvent d’une mauvaise compréhension ou d’une mauvaise gestion de celle-ci.
Reprenons. Vous avez un logiciel qui peut s’utiliser de plein de façons différentes, et pour lequel les créateurs – vous, peut-être ? – ont créé autant de possibilité de configuration. Pour éviter aux utilisateurs de ce logiciel de passer des heures à paramétrer des trucs avant de pouvoir l’utiliser, ils ont défini des configurations par défaut, et c’est très bien.
Mais vous, vous avez modifié une configuration.
J’ai plusieurs fois entendu dire du bien d’un logiciel parce qu’il est hautement configurable.
Ça aussi, c’est souvent une fausse bonne idée.
Une option de configuration, c’est :
- Le code correspondant à développer, tester, documenter et maintenir ;
- Une source de bugs en plus ;
- Une source de vulnérabilités en plus.
Créateurs, ne créez pas d’option de configuration sans vous demander sérieusement si elle est indispensable et intéressante par rapport aux problèmes qu’elle apporte. Mettez une valeur par défaut qui ira bien au plus grand nombre.
Utilisateurs, utilisez les valeurs par défaut tant que c’est possible.
Le problème n’est pas que vous ayez modifié cette configuration, ni même que vous ayez fait une erreur dans la manœuvre – car oui, vous avez fait une erreur, subtile. Non, le problème est que l’application, détectant une configuration erronée, a basculé dans le silence sur un comportement par défaut.
Et comme l’erreur n’est pas triviale, elle est difficile à voir.
Et comme il y a un comportement par défaut, l’application ne plante pas, elle fonctionne – mal, pas comme prévu, mais fonctionne.
Et comme cette bascule est silencieuse, vous ne savez pas que votre application fonctionne avec autre chose que la configuration demandée1.
Ce qui nous amène à ceci :
Vous devez interdire à vos programmes de fonctionner avec des configurations qui n’ont pas de sens. Si c’est impossible, mettez des logs très visibles.
Ceci implique de planter au démarrage (oui, refuser de démarrer !) si vous pouvez détecter une configuration qui a une valeur impossible.
Si cette détection rapide est impossible (parce que la validation ne peut se faire qu’une fois le programme déjà en service), basculez sur le comportement de la configuration par défaut et surtout logguez le problème avec un haut niveau de priorité2. Parce que le problème est tout sauf anodin : l’utilisateur a explicitement demandé un comportement qu’il ne pourra pas avoir.
Vos utilisateurs, donc vous-même dans peu de temps, vous en remercieront.
- Oui, j’ai croisé des logiciels pour lesquels « une configuration qui ne peut pas être appliquée » ne donne pas le même résultat que « pas de configuration du tout » ou « la configuration par défaut »…↩
- J’ai aussi croisé un logiciel qui logguait ce problème, mais en niveau
debug. Autant dire invisible dans la masse de messages quand on active – enfin – ce niveau de traces.↩
Icône d’après cette image dans le domaine public.
