Idéalités

Comme on nous l'apprend, pour "bien" conduire, il faut regarder au loin, vers l'horizon, de façon à anticiper les dangers, les changements de direction, etc., afin d'adapter sa conduite en conséquence.

Si nous regardons le bout du capot, aucune anticipation n'est possible. Si nous regardons sur le côté, nous allons dans le décor. Nous allons en quelque sorte mécaniquement vers là où porte notre regard. Regarder l'horizon permet de maintenir un cap et d'anticiper.

Le développement logiciel fonctionne de la même façon: sans une vision claire de l'horizon et sans viser cet horizon, il n'y a pas d'anticipation possible. Cette anticipation est nécessaire pour munir le logiciel d'un potentiel d'évolution dans la direction de cet horizon. On pensera à des structures de données pouvant s'enrichir pour répondre à de nouvelles fonctionnalités prévisibles, ou bien à une forme de généricité et d'abstraction permettant de supporter certaines variations des hypothèses, de l'environnement.

Pour un logiciel implémentant des recherches, il me semble important d'avoir une idée de la direction prise par ces recherches, de façon à laisser le logiciel ouvert par rapport à cet avenir inconnu.

Qu'est-ce alors que l'horizon pour un logiciel ?

Je pense que l'objet en question, l'horizon visé lors du développement d'un logiciel, est une idéalité d'un certain type. L'extrait suivant provient du cours de Bernard Stiegler sur Pharmakon.fr (saison 1, épisode 2 (i.e. année 2010-2011, cours numéro 2 du octobre 2010), de 39'26'' à 49'50''):

Ce que vise le développeur d'un logiciel ressemble fort au jaune que poursuivait Van Gogh.

Dans "Les idéalités mathématiques", Jean-Toussaint Desanti prend comme exemple d'idéalité notamment l'ensemble des sous-ensembles d'un ensemble infini: son existence ne peut être prouvée et il n'y a pas de manière de le construire effectivement. L'axiome du choix pose l'existence de cet ensemble et est ensuite utilisé pour prouver, déduire d'autres propriétés.

La position de l'existence de cet ensemble (des sous-ensembles d'un ensemble infini) fait de lui une idéalité: il n'est pas défini par une façon de le construire, mais on admet son existence. Lorsque le mathématicien s'appuie sur cette existence, c'est-à-dire lorsqu'il utilise, directement ou indirectement, l'axiome du choix, cette idéalité consiste dans les nouvelles propriétés déduites.

L'enchaînement des déductions propage en quelque sorte la consistance de l'idéalité dans les différentes propriétés et théorèmes s'appuyant in fine en partie sur l'axiome du choix.

Au contraire, lors du développement d'un logiciel, l'idéalité poursuivie sert de cap, d'horizon pour les développements permettant de mener vers cette idéalité. Si ces développements ne s'appuient pas sur cette idéalité dans le même sens qu'avec l'axiome du choix, l'idéalité "Logiciel" visée n'en consiste pas moins dans le logiciel créé puisqu'elle a orienté tout son développement. Le chemin parcouru vers cette idéalité a fixé les directions d'évolution du logiciel.

Une idéalité mathématique ne peut servir de base au développement d'un logiciel de la même façon que l'axiome du choix pour des preuves car un logiciel doit se résumer à des calculs. Or, le calcul de l'ensemble des sous-ensembles d'un ensemble infini n'est pas défini.

Cela n'empêche pas de considérer localement des objets comme des idéalités au sens de Desanti. Ainsi les paramètres d'une fonction peuvent être considérés comme de telles idéalités: on admet l'existence des objets qu'ils désignent et ces derniers consistent dans les calculs de la fonction. Il revient à l'appelant de la fonction d'assurer l'existence des objets à passer en paramètres.

Dans le cours numéro S1E11, 2ème partie. de Pharmakon.fr, Stiegler introduit la notion de régime d'idéalité. Il semble clair ici que le régime des idéalités mathématiques est différent du régime des idéalités "Logiciel" dans le sens du jaune de Van Gogh.

Cependant, lorsque l'idéalité Logiciel est implémentée (si on considère que cela est possible, cf. plus bas), il est alors possible de prouver qu'elle donne le résultat attendu ou non, en effectuant des preuves sur le programme final. Est-ce à dire que le régime des idéalités Logiciel se soumet en quelque sorte à un autre régime d'idéalités permettant les démonstrations ?

En fait, non, car l'objet dont on est tenté de démontrer la correction par rapport à un résultat attendu n'est pas un logiciel, mais un programme, un objet fini. L'idéalité Logiciel consiste dans ce programme au travers notamment de sa structure. Comprendre cette structure permet éventuellement de deviner l'idéalité ayant présidé à l'écriture du programme. L'idéalité elle-même est infinie, elle est le potentiel d'évolution.

Il est tout à fait possible d'imaginer un logiciel offrant des fonctionnalités avancées et se rendre compte ensuite de l'impossibilité d'implémenter ces fonctionnalités. La question de savoir si l'implémentation est correcte ou même possible n'intervient cependant pas dans le fait que l'idéalité dirige la structure.

Le développeur ayant d'une part à coeur d'obtenir un programme utilisable et correct, d'autre part une conscience ou une intuition de ce qui est possible pour un programme, bridera ou orientera en conséquence l'idéalité qu'il poursuit, quitte à faire quelques concessions à ses rêves.

J'ai déjà plusieurs fois utilisé le terme de "poursuite" pour désigner le fait de développer un logiciel: Il s'agit bien de poursuivre l'idéalité Logiciel comme on poursuit un rêve, réaliser ce rêve en parvenant à implémenter l'idéalité, en faisant en sorte que ses principes, son élégance et sa beauté consistent dans le programme final.

Cependant, tout comme l'horizon reculant au fur et à mesure que l'on avance dans sa direction, l'idéalité Logiciel s'éloigne au fur et à mesure qu'elle est exprimée dans le code. De nouvelles idées viennent au développeur comme autant de de nouveaux rêves.

C'est ce qui fait qu'un logiciel n'est jamais fini: Il implémente une idéalité passée, remplacée ou complétée par une nouvelle, surgie de la compréhension d'un problème comme après le passage d'une montagne qui bouchait l'horizon, ou surgie de nouvelles possibilités offertes et accessibles comme après un virage. La structure d'un logiciel reflète cette histoire des idéalités poursuivies, avec ses virages, ses changements de cap, ses problèmes rencontrés et surmontés.

Si je compare la poursuite de l'idéalité Logiciel à la poursuite d'un rêve, c'est qu'il s'agit bien de désir dans l'activité de développement logiciel. Ce désir pour l'horizon, cette attente de cet horizon est ce qui permet l'anticipation, et donc le potentiel d'évolution du logiciel dans la direction de cet horizon.

L'horizon est différent d'un objectif, car la poursuite d'un objectif n'est pas sans fin: l'objectif ne recule pas lorsqu'on avance vers lui. On ne poursuit pas un objectif, on avance seulement vers lui. Si l'on ne regarde pas au-delà de cet objectif, l'état dans lequel on arrive à cet objectif est privé de potentiel d'évolution, ou bien ce dernier est orienté selon une direction non choisie.

La motivation pour l'activité de développement logiciel est donc bien plus profonde qu'une simple liste d'objectifs à atteindre pour obtenir, par exemple, de l'argent.

Tout développeur a un jour expérimenté la pénibilité de commenter son code alors que ce dernier fonctionne déjà et que le développeur veut aller plus loin. La rédaction a posteriori des commentaires explicatifs, justificatifs, semble n'être qu'une redite de ce que le développeur a exprimé par le code.

En effet, l'écriture de ces commentaires, étant une autre manière d'exprimer l'idéalité originale, n'est plus motivante, car le désir du nouvel horizon a remplacé celui de l'idéalité originale. La rédaction des commentaires donne l'impression de refaire un chemin déjà parcouru alors qu'on désire le prolonger.

La motivation pour rédiger des commentaires vient plutôt, à mon avis, de deux choses:

• le désir de transmettre et partager sa vision de l'idéalité poursuivie, comme un balisage du chemin parcouru pour permettre à un développeur de le suivre ultérieurement (y compris le développeur original),
• le désir de bien faire son travail, en tant qu'artisan, en ayant une pensée pour celui ou celle qui reprendra et poursuivra le travail.

Dans les deux cas, il me semble qu'il s'agit de faciliter non seulement la maintenance du logiciel mais surtout la poursuite de l'idéalité qui a présidé à son développement. Il s'agit donc ni plus ni moins d'offrir une immortalité à l'auteur qui a fait consister cette idéalité, idéalité que les autres à leur tour peuvent poursuivre et qui continuera de consister dans les travaux s'appuyant sur elle ou héritant d'elle.

A suivre: Les questions de "partage d'idéalité", par exemple dans une communauté de développeurs, et de la confiance, lorsqu'il s'agit d'accueillir un développeur ou une contribution.