Le rasoir d'Ockham

Lors de la récente lecture du "Rasoir d'Ockham" écrit par Henri Loevenbruck, j'ai redécouvert une fois de plus le principe de parcimonie énoncé comme suit:

" Les entités ne doivent pas être multipliées par delà ce qui est nécessaire ".

Appliqué à l'enquête criminelle du livre, ce principe voulait "ne pas multiplier les suppositions pour expliquer un méfait".
Ainsi, l'on se concentrera sur l'explication la plus simple et la plus évidente. Si cette dernière n'est pas la bonne, elle ne résistera pas à la démonstration de son bien fondé. Il sera alors encore temps d'envisager une autre hypothèse.
Comme mentionné par l'auteur, il y a divers avantages à l'application de cette méthode:

1. On ne s'encombre pas l'esprit avec de multiples suppositions qu'il est difficile de démontrer.
2. Le temps nécessaire au traitement de l'hypothèse la plus simple est réduite au minimum (plus facile de mener une seule guerre de front).
3. L'esprit n'est pas encombré par des hypothèses inutiles. Par conséquent la complexité du raisonnement s'en trouve allégé. Avec la simplicité, le risque d'erreur diminue également.
   
4. Dans plus de 80% des cas, l'explication la plus simple est celle qui convient.
   

Ce principe de raisonnement datant du XIV ieme siècle refait régulièrement surface dans mes lectures tout comme dans mon travail.
Mais quel est la rapport entre le principe de parcimonie/d'économie d'Ockham et les développements informatiques ?

Et bien, j'ai le sentiment qu'en ce qui concerne les développements, le principe du Rasoir d'Ockham doit être appliqué à rebours.
Non pas qu'il faille compliquer inutilement le logiciel (workflow, coding, behavior) mais bien au contraire, garder le tout d'une telle simplicité et limpidité que le principe du Rasoir d'Ockham soit également applicable au logiciel.
S'il est possible de prévoir et comprendre le comportement d'un logiciel (ou composant logiciel), il est alors possible de prévoir son influence dans un système plus complexe.
Dans le cas contraire, toutes zones d'ombres n'autorisant pas l'évidente compréhension du logiciel (ou composant logiciel), met en péril la stabilité du système dans son ensemble.
Ainsi, on veillera à ne pas compliquer, plus que nécessaire, les fonctionnalités et le développement d'un logiciel.

Dans le même ordre d'idée, il est plus simple pour l'utilisateur de concevoir le fonctionnement d'un logiciel comme

un séquenceur exécutant un enchainement des tâches simples

que d'appréhender

les multiples combinaisons/possibilités de fonctionnements d'un module paramétrable à outrance.

Une succession de règles et processus simples et invariables est plus faciles à comprendre (1) qu'une combinaison/multiplication de paramètres d'un module qui deviennent, avec le temps, totalement obscurs (et dont l'expression est quelquefois hasardeuse) (2).

Et ce qui est valable pour un utilisateur l'est forcement pour le concepteur, les analystes, les développeurs, les consultants, etc.
C'est ainsi, selon moi, que l'on obtient des logiciels faciles à maintenir et évolutifs.

Il est d'ailleurs plus facile de réutiliser un composant logiciel dont il est facile de comprendre le comportement... et donc de le prévoir (ce qui n'est pas à démontrer... j'espère).
Le comportement n'est prévisible que si le composant logiciel a été conçu comme tel... pour être évident à comprendre... parce qu'il autorise l'application du principe du rasoir d'Ockham... par lequel le concepteur à voulu qu'une fonctionnalité puisse s'expliquer par un principe d'évidence.

Les systèmes Linux sont basés sur cette philosophie de simplicité, de parcimonie, d'économie d'effort (les composants ne font pas "grand" choses mais ils le font bien).
C'est ainsi que le monde du développement libre à accouché de son propre système d'exploitation... en réutilisant des composants simples mais prévisibles pour en construire d'autres plus complexes... mais toujours aussi simple a comprendre.
L'émergence des principes KISS (Keep It Simple Stupid) dans le monde du développement n'est d'ailleurs qu'une expression plus "contemporaine" du principe de parcimonie.

Encore un doute sur les principes de parcimonie lors de la conception (logicielle ou autre)?
Et bien dans ce cas, n'utilisez plus de voiture ou de téléphone mobile... car ils en sont le résultat...
Dans le cas d'une voiture, par exemple, chaque pièce est simple, l'assemblage final est complexe... cependant l'utilisation en reste simple et le fonctionnement prévisible (surtout sur les modèles plus anciens).
Avec un peu d'acuité il est même possible, au néophyte, de deviner l'origine d'une panne.
Même les inconvénients d'électroniques de bord peuvent s'expliquer par le simple fait que cette partie du système recèle une telle complexité qu'il n'est plus possible d'en comprendre (facilement) le fonctionnement et d'en prévoir le comportement.
Cette "zone d'ombre" dans les paramètres du véhicule échappant au principe de parcimonie (de simplicité) et met en péril le système entier... et la voiture ne démarre pas.


1) C'est bizarre comme cette dernière phrase focalise mon esprit vers le développement basé sur des moteurs de gestion de Workflow .
2) La formulation "L'expression des paramètres" me fait à l'instant penser à la génétique.
Est-ce qu'un logiciel fortement paramétrable (et par conséquent presqu'imprévisible s'il est suffisamment gros) peut être, en quelque sorte, considéré comme un système de "génétique" :-) ?
Bon, ce n'est pas vraiment évolutif... sauf si l'on considère les effets de bords (induit pas les paramètres générant des données erronées) pouvant eux-même induire d'autres effets de bords... c'est presque de l'intelligence artificielle ça, non?
Note - 27/08/2008: Comme me l'a le fait remarquer Jyce, ma parabole sur l'intelligence artificielle est tendancieuse et pourrait induire le néophyte dans l'erreur. Je partage son avis.
Donc, en gros, un système d'intelligence artificielle n'est pas une système hautement paramétrable mais plutôt un système évolutif capable d'adapter ses propres paramètres tout seul (par l'apprentissage) pour atteindre seul le but qui lui a été fixé.

Lien utiles:
Rasoir D'Ockham sur Wikipedia