Un de mes lecteurs m’a demandé si l’esthétique, la notion de « beau », pouvait s’appliquer au logiciel. À mon avis, la réponse est oui. À condition de s’entendre sur ce qu’est un « beau logiciel ».

Il y a d’abord l’esthétique du logiciel considérée du point de vue de l’utilisateur. C’est un attribut de la qualité. La dernière version de la très sérieuse norme ISO/CEI 9126 sur la qualité du logiciel, ainsi que la série normative ISO 25000 qui lui a succédé, présentent l’attractivité comme une sous-caractéristique de l’utilisabilité. L’attractivité a beau être subjective, elle est mesurable.

Sous prétexte d’immatérialité, un produit logiciel a-t-il le droit d’être laid ? A-t-on le droit d’agresser l’utilisateur avec des produits mal faits, bâclés, incohérents ? Certes, les outils et méthodes actuels permettent de développer sans trop d’efforts et sans trop de risques des applications beaucoup plus ergonomiques qu’il y a trente ou quarante ans. Cela n’empêche pas les applications confuses, surchargées et difficilement navigables, ne correspondant en rien aux règles les plus élémentaires de l’ergonomie.

« La laideur se vend mal » proclamait Raymond Loewy, un des fondateurs du design industriel. Cette affirmation est également vraie pour logiciel : l’utilisateur est sensible à l’esthétique. Un logiciel agréable à utiliser aura un impact positif sur sa productivité.

D’autre part, l’esthétique d’une application informatique, notion certes toute subjective et intuitive, est un bon indicateur de qualité. Il m’est arrivé de mener quelques audits d’application. Et comme dans beaucoup de domaines, ce qu’on voit en vitrine donne souvent un avant-goût de ce qu’on va trouver dans l’arrière-boutique. Si l’interface utilisateur est laide, s’il est difficile de s’y retrouver dans les menus, c’est très souvent qu’elle a été mal pensée, et il y a des chances que les caractéristiques internes (efficacité, maintenabilité, et fiabilité) ne soient pas au rendez-vous.

Voilà pour la façade. L’esthétique de l’interface est perceptible par tous. Mais il y a aussi la beauté intérieure et, dans le cas d’un produit logiciel, cela demande quelques explications. Je voudrais vous montrer ce que j’entends par la « beauté intérieure » du logiciel, même si vous n’en avez jamais développé.

Une caractéristique de qualité qu’on ne trouve ni dans la norme ISO 9126 sur la qualité du logiciel, ni dans la norme Afnor Z 67-133-1 sur l’ergonomie des interfaces utilisateur, ni dans aucune norme, et qui est à mon avis fondamentale. C’est l’élégance.

Les développeurs savent ce qu’est un logiciel mal écrit, inutilement compliqué, peu lisible, difficilement maintenable, comprenant des fonctions inutiles, voire des fonctions auxquelles l’utilisateur ne peut pas accéder (je vous assure, ça existe !). Ce que j’appelle un logiciel élégant, c’est un logiciel qui ne comporte aucune fonction inutile, qui n’est pas inutilement complexe, et dont les fonctions, ainsi que leur documentation, sont aisément accessibles.

Ces caractéristiques peuvent être automatiquement mesurées au moyen d’outils du marché. L’analyse du code source d’un logiciel permet d’en mesurer la « laideur », avec des indicateurs tels que la mesure de la complexité pathologique (pathological complexity metric) de McCabe, qui donne une indication du « combien le programme est mal structuré », c’est-à-dire inutilement complexe, inélégant.

Ce que j’entends par élégance peut aussi être perçu intuitivement, même pour une personne qui n’a jamais développé de logiciel. Pour saisir ce concept, je vous propose une analogie avec une activité beaucoup plus ancienne : le génie civil.

Détour par les ouvrages d’art

Dans les années 1930, l’ingénieur Suisse Robert Maillart a acquis sa réputation en construisant un grand nombre de ponts en béton armé. Les techniques qu’il utilisait étaient alors révolutionnaires. La forme de ses ouvrages d’art sortait de l’ordinaire. Ses travaux étaient controversés et ses détracteurs de l’époque étaient plus nombreux que ses admirateurs. Cependant, il a pu gagner un grand nombre de contrats, non pour des raisons d’esthétique, mais essentiellement pour des raisons de coût. Les ponts de Maillart coûtaient moins cher que ceux des concurrents, car ils utilisaient une quantité moindre de béton.

Plutôt que de copier les formes classiques des ponts de pierre, Maillart a innové en exploitant au maximum les propriétés de ce nouveau matériau qu’était alors le béton armé. Doué d’un sens esthétique très sûr, il n’acceptait qu’avec réticence la collaboration des architectes. Il a refusé l’ajout d’éléments purement décoratifs : l’esthétique de l’ensemble devait résulter de la forme de l’ouvrage, qu’il a toujours eu le souci d’épurer. Il en est résulté des constructions que nous considérons aujourd’hui comme élégantes.

Au début du vingtième siècle, les sciences de l’ingénieur ont fait d’énormes progrès, entre autres grâce aux apports de l’analyse mathématique. C’est le calcul des structures qui a permis d’évaluer précisément la résistance d’un pont et la charge que celui-ci pouvait porter. Cependant, cette formalisation a également eu l’effet contraire : si une structure ne pouvait être calculée, on considérait qu’elle ne pouvait pas être construite. Comme dans d’autres domaines, l’excès de formalisme est un frein à l’imagination.

Pour concevoir ses ponts, Maillart faisait appel à son intuition plutôt qu’aux mathématiques. Des schémas simples remplaçaient les calculs complexes. Il raisonnait par analogie. C’est ainsi que, pour concevoir la base cylindrique d’un château d’eau, il s’est inspiré de la construction des tonneaux, renforcés d’anneaux métalliques.

D’une construction à l’autre, Maillart tirait parti de ses erreurs, afin de perfectionner sa technique. Il remettait incessamment en question la conception de ses ouvrages précédents. Il recherchait la simplicité et l’esthétique. Quand on observe l’évolution de ses ouvrages dans le temps, on s’aperçoit que leurs lignes deviennent de plus en plus épurées.

Retour au logiciel

Quels enseignements peut-on tirer des méthodes de construction de Robert Maillart ? Ces méthodes peuvent-elles être utilisées pour concevoir et réaliser du logiciel ? certes, il y a de grandes différences entre un une application informatique et un ouvrage d’art en béton armé, mais il y a aussi plusieurs analogies.

Tout d’abord, quelle que soit la discipline considérée, l’excès de formalisme tue l’innovation. Bien entendu, il n’est pas question de se passer du formalisme, mais de le mettre de temps à autre de côté pour réfléchir librement. Il y a danger d’appauvrissement de la pensée lorsque celle-ci est subordonnée au formalisme. Maillart prenait le risque de faire construire des ponts dont la validité n’était pas démontrée mathématiquement. On peut transposer cette approche au logiciel … tout en restant rigoureux sur le fond. L’expérience, l’intuition et les échanges entre individus peuvent souvent, et doivent parfois, prendre le relais sur le respect des procédures. C’est d’ailleurs un point essentiel des démarches agiles.

D’autre part, lorsqu’un formalisme est trop complexe pour être appliqué, il peut souvent être remplacé par un schéma simple. Les schémas de Maillart n’entraient pas dans tous les détails de la réalisation ; ils aidaient à visualiser ce que les moyens de calcul de l’époque ne pouvaient modéliser : des forces, des tensions. De manière analogue, on peut faire l’économie de diagrammes compliqués et ne garder que l’essentiel.

En troisième lieu, l’efficacité découle souvent de la simplicité. Les surcharges n’apportent aucune valeur au logiciel. Si l’on ne cherche pas à faire volontairement simple, le client demande du superflu, les concepteurs surenchérissent, les développeurs se font plaisir, et le résultat ressemble à un arbre de Noël dans la vitrine d’un grand magasin. Qu’il s’agisse de l’architecture d’ensemble ou de l’interface utilisateur, le superflu nuit à la qualité.

Enfin, la méthode itérative utilisée par Maillart lui a permis de d’améliorer sa technique à chaque réalisation d’un nouvel ouvrage d’art. Et on sait à quel point l’amélioration itérative peut être efficace dans le cadre du développement de logiciel.

De manière générale, on peut dire que l’esthétique est très souvent un indicateur de la qualité. Derrière une interface utilisateur disgracieuse, derrière une difficulté de navigation ou une symbolique incompréhensible, qui constituent la surface d’une application, on trouve très souvent une architecture logicielle mal pensée et des méthodes de développement mal utilisées.

© Yves Constantinidis, 2022