La méthode essais-erreurs

La méthode essais-erreurs connaît une certaine popularité dans les milieux pédagogiques et bureaucratiques. On essaie des projets, et on se dit qu'en cas d'échec, il sera toujours temps de rectifier le tir. Bref, le bon sens populaire veut qu'on apprenne de nos erreurs. On se demande rarement si le projet, qui mobilise nécessairement des ressources humaines et financières, aurait gagné à être soigneusement planifié. Non seulement bon nombre de projets consistent à tuer des mouches avec des boulets de canon, mais ils échouent souvent, quand ils ne font pas carrément plus de mal que de bien.

La méthode « tuer des éléphants avec une carabine à plomb » compte également beaucoup d'adeptes chez les pédagos.

Les échecs sont pourtant facilement prévisibles, mais le dogme de la méthode essais-erreurs, hérité d'une religion que l'on pourrait nommer psychologie de la paresse, empêche toute réflexion préalable. Quand on gère les deniers des autres, quand les échecs ne sont pas sanctionnés ni les succès récompensés, pourquoi se préoccuper d'efficacité?

Il existe pourtant un domaine exemplaire où la méthode essais-erreurs est considérée comme une dangereuse fumisterie : il s'agit de l'informatique.

Les méthodes modernes de programmation visent à réduire la complexité afin de prévenir les erreurs. C'est ce qui permet, année après année, la production de logiciels de plus grande envergure, de meilleure qualité, et moins coûteux en temps et en argent. L'utilisation de métaphores est une des façon des réduire la complexité du développement logiciel.

Steve McConnell, dans son classique intitulé Tout sur le code, explique pourquoi la métaphore logicielle la plus productive actuellement est celle de l'architecture. Avant de construire une maison, on examine les besoins de ses habitants et les fonctions qu'elle devra remplir (le même principe vaut pour le développement d'un logiciel). On établit ensuite un plan général. Les détails du plan, pourront être définis plus tard, surtout s'ils n'ont pas d'influence sur la structure. Il reste alors à construire la maison, en respectant les normes en vigueur, tout en vérifiant le travail en cours de route et en se réajustant si nécessaire. En informatique, cette dernière étape serait celle de la programmation proprement dite, qui s'appuie également sur un plan précis et des règles bien établies.

Une des métaphores les plus répandues dans le public consiste plutôt à comparer le programmeur à l'écrivain typique du cinéma hollywoodien. On imagine un bonhomme enfermé dans une pièce, avec ses accessoires incontournables : un clavier, un cendrier et une corbeille pleine de boulettes de papier. Il pitonne, il griffonne, il se relit, il fait la grimace, il chiffonne, il lance la boulette dans la corbeille et il recommence. Non seulement cette métaphore n'est qu'une image d'Épinal, mais elle s'avère désastreuse pour l'informatique, qui doit s'appuyer au contraire « sur une conception et une organisation soignée » (Tout sur le code, Steve McConnell, Microsoft Press, page 17).

La méthode essais-erreurs est l'apanage de l'animal.
(Le philosophe Sergei)

Que fait le mauvais programmeur quand il teste un logiciel en développement? Lorsqu'il se retrouve face à une erreur, nous dit Steve McConnell, ce mauvais programmeur « se contente d'essayer différentes choses jusqu'à ce que l'une d'elle semble fonctionner, c'est-à-dire de programmer par essais et erreurs » [plutôt que chercher à comprendre son propre programme]. Selon le gourou de la programmation informatique, cette méthode laisse non seulement échapper la plus grande majorité des erreurs existantes, mais elle a pour effet d'ajouter des erreurs nouvelles.

La méthode essais-erreurs doit-elle donc être proscrite à tout prix? Lors d'une première étape d'exploration et de « remue-méninges », elle peut s'avérer productive. Mais dès qu'il s'agit de passer à l'action, elle est presque toujours l'apanage des idiots ou des irresponsables.