L’informatique est-elle une science ?

Quelques définitions

Par science, on entend domaine de la connaissance, à différencier de la technologie, qui traite des outils et des techniques ; je parlerai donc ici de l’informatique comme domaine de connaissance, pas comme ensemble de pratiques et de techniques.

Pour caractériser une science, il faut déterminer son objet d’étude, sa méthodologie et la façon dont elle prouve ses résultats. Aussi ancienne que soit la science, répondre à cette question n’est jamais trivial. La physique est supposée comprendre et modéliser les phénomènes naturels, mais cette définition est tellement large qu’elle pourrait englober la chimie et la biologie ; cette dernière est supposée étudier le vivant, mais nous n’avons pas aujourd’hui de définition satisfaisante de ce qu’est la vie, et ainsi de suite. Y répondre pour l’informatique est tout aussi difficile.

L’objet d’étude

Trois objets sont susceptibles d’être l’objet de l’informatique : les algorithmes, les ordinateurs et les informations.

Le terme d’algorithme a gagné en popularité dans le grand public ces dernières années : il représente symboliquement la puissance de Google, les risques réels ou supposés des réseaux sociaux et du big data, voire plus récemment de l’intrusion de l’Etat dans les communications électroniques. Il possède une certaine charge magique qui ferait de nous informaticiens des égaux de Newton ou Einstein avec leurs lois universelles, génies aux pouvoirs mystérieux et absolus. Plus prosaïquement, un algorithme n’est guère plus qu’une recette de cuisine pour transformer un jeu de données entrant en un jeu de données sortant ; en tant que tel, son étude peut être passionnante, et d’une incroyable difficulté technique et conceptuelle – ceux qui auront tenté de démontrer qu’il n’existe pas d’algorithme de tri plus rapide que le quick sort sauront de quoi je parle. Mais aussi fondamentaux qu’ils soient en informatique, les algorithmes sont nés bien avant elle, et sont étudiés depuis bien longtemps par une branche des mathématiques, l’algorithmique ; leur formalisme et leur étude en empruntent toutes les caractéristiques. Ils ne peuvent être l’objet unique de la science informatique.

L’objet ordinateur a l’avantage d’être apparu peu ou prou en même temps que l’informatique. Celle-ci serait dans ce cas la science étudiant l’ordinateur en tant que dispositif de traitement automatisé des données – notez l’utilisation du terme données et pas du terme information, on va y venir – pour résumer, l’étude des machines de Turing. Comme l’indique le sous-titre de ce blog, je ne suis pas partisan de définir l’informatique par l’outil ordinateur : d’une part, cela tend à la réduire à un ensemble de technologies, or nous essayons de la définir en tant que science, et d’autre part, en elle-même, sans algorithme, sans les données introduites et les données attendues en sortie, la machine est inerte.

L’information est à différencier de la donnée en ce qu’elle regroupe deux réalités : les données proprement dites, et leur mise en forme. La donnée est objective, c’est elle que traite la machine ordinateur ; l’information est subjective en ce que la mise en forme des données est interprétée humainement. Pour comprendre la différence, il suffit de penser par exemple aux sondages : le nombre de personnes choisissant une réponse à une question est une donnée ; ce que ce nombre dit de la réalité de la population sondée est une information, sujette à l’interprétation du sens de la question, du sens de la réponse dans le cadre de la question, de la situation du répondant quand on lui pose la question, etc. Telle que définie ici, elle est un objet d’étude original qu’aucune autre science n’aborde centralement : la linguistique étudie les messages exprimés dans les langues humaines, mais par définition tend à ignorer l’objectivité de la donnée sous-jacente qui dans son domaine est une illusion ; les mathématiques jouent avec les données, mais ne s’intéressent pas au sens subjectif que les humains leur affectent. De plus, la dualité donnée objective – interprétation humaine subjective représente bien la problématique rencontrée en permanence par les informaticiens qui est d’optimiser un processus existant à l’aide des ordinateurs – voire sans parfois.

C’est pourquoi, si je devais définir un objet unique d’étude de l’informatique, ce serait l’information ; raison également pour laquelle j’apprécie particulièrement le mot français informatique, quand les américains parlent plutôt de computer science  – un reflet de leur culture utilitariste ?

Méthodologie et preuve

Malgré les bons arguments que l’on peut donner pour affirmer que l’objet de l’informatique est l’étude des informations, dès qu’on se penche sur la méthodologie informatique et sa façon de prouver la pertinence de ses résultats, les algorithmes et les machines reviennent en force.

En effet, il s’agit ici de démontrer qu’un traitement de l’information est conforme formellement aux demandes exprimées initialement par des humains. Ces demandes peuvent revêtir plusieurs formes : que les informations en sortie correspondent bien aux entrées et aux traitements demandés, ce qui fait appel à l’algorithmique ; que les traitements respectent des impératifs de rapidité, ce qui fait appel à l’expérimentation sur les machines. La qualité des traitements ne peut pas toujours se passer de l’interprétation humaine – d’aucuns dirait rarement – or si on savait modéliser correctement un humain, ça se saurait ; on peut prendre l’exemple de la vallée de l’étrange pour les robots où le ressenti humain est le cœur de la recherche. Dans ces cas, l’expérimentation sur des machines physiques est indispensable et l’ingrédient humain rend la preuve formelle difficile voire impossible.

La spécificité de la méthodologie informatique est de combiner les outils algorithmiques et les preuves empiriques par déploiement des traitements sur des machines physiques en une approche commune.

En conclusion, je pense que l’informatique traite un sujet original avec une approche elle aussi fondamentalement originale ; les objections légitimes à ce fait sont applicables à toutes les sciences du réel – la Physique moderne n’existerait pas sans les mathématiques, la Biologie s’appuie sur la Chimie, la Chimie sur la Physique, etc. Gageons qu’en mûrissant – 70 ans est très jeune pour une science, la plupart des concepts scientifiques mettent plus d’un siècle à percer dans la société civile – son objet et ses méthodes se cristalliseront de façon incontestable.

Des outils et des hommes

Ma première rencontre avec un outil automatisé d’aide au développement logiciel remonte à ma troisième année d’école d’ingénieur en option ingénierie du logiciel. L’outil en question, dont j’ai oublié le nom, évaluait la qualité du code par le calcul d’un lot de métriques et leur comparaison avec des seuils prédéfinis. Parmi ces métriques se trouvaient le nombre de lignes de code par fonction, le nombre de lignes de commentaires par ligne de code et la présence de commentaires en cartouche d’une méthode, le nombre d’utilisations d’une fonction ou méthode, etc. Une fonction trop longue – de mémoire, plus d’une centaine de lignes, une fonction non commentée – aussi triviale soit-elle, ou une fonction trop utilisée, déclenchaient des torrents d’insultes de la part de l’outil qui se montrait assez à cheval sur ses principes. Appliqué sans discernement, comme dans les travaux pratiques de ce cours, ce genre d’approche kafkaïenne amène à des sommets de la littérature informatique tels que :

/* Sets the threshold (no shit, it really does) */
public void setThreshold(int threshold) {
  this.threshold = threshold;
}

voire à des abominations du genre :

public void thisMethodIsReallyTooLong() {
  /* does lots of interesting things, and then, when the metric is about to be exceeded... */
  thisMethodIsReallyTooLongPart2();
}

public void thisMethodIsReallyTooLongPart2() {
  /* Now, where were we? */
}

Non seulement la règle a dégradé la lisibilité du code, mais qui pis en fonction de la bonne volonté du compilateur, elle peut même avoir réduit les performances. J’ai appliqué les règles comme on me le demandait et je suis passé à autre chose.

Une fois en situation d’organiser la réalisation de projets pour mes clients, la question des outils s’est posée à nouveau. Editeur de texte, IDE, contrôle de source, générateurs de code, tests unitaires automatisés, intégration continue, déploiement, les outils sont nombreux, résolvent des problèmes très variés et ont des avocats véhéments prompts à l’anathème. En tant que décideur, quels critères appliquer dans ses choix ?

Fidèle à mes principes, je ne m’engage dans la mise en place d’un outil que si il répond à un problème identifié ; je ne pense pas qu’il existe un seul développeur professionnel qui n’ait été confronté à des régressions – « mais je l’avais corrigé ce bug, qui a écrasé mon code ? » – ou à la gestion de versions de ses développements : un système de contrôle de source s’impose donc à tous. A l’inverse, une équipe sortant une version publique tous les ans au plus a-t-elle besoin d’un système d’intégration continue, avec le coût de mis en oeuvre inhérent à ce type d’outil complexe ? Rien n’est moins sûr. Tester voire déployer systématiquement tous les derniers outils à la mode en évaluant mal leur pertinence dans le contexte local est un indicateur certain du mauvais décideur.

Par ailleurs, un outil n’est rien s’il n’est pas pris en main par l’équipe. Naturellement, le décideur aura tendance à se méfier des membres de l’équipe qui auront soutenu vocalement d’autres outils que celui de son choix. Le « fanboy »  d’un outil concurrent induit effectivement un risque, mais il est une quantité connue : il sera mécontent que sa préférence ait été mise de côté, mais ayant compris ce que pouvait apporter ce type d’outil, il sera probablement à même d’utiliser correctement le choix du décideur – à moins d’être une tête de cochon n’ayant pas très bien intégré les notions d’équipe et de compromis, auquel cas il serait sans doute mieux tout seul, mais c’est une autre histoire.

La passivité est bien plus pernicieuse, car elle est la marque soit d’un désintérêt total pour la question, soit d’une incompréhension des enjeux, et au pire d’une incapacité à intégrer correctement l’outil dans sa pratique quotidienne.

On l’a vu, appliquer à la serpe des métriques amène à des aberrations ; l’usage correct est donc d’utiliser les seuils comme des avertissements à traiter manuellement avec discernement. Mais encore faut-il comprendre l’avertissement, ne pas simplement le désactiver pour avoir la paix, et le traiter correctement – par exemple analyser une fonction longue pour déterminer si elle n’est pas découpable en unités signifiantes plus petites, mais ne pas la charcuter pour le plaisir. Utiliser des branches pour matérialiser des lignes de développement séparées – la version 1.0 en cours de maintenance, la version 1.1 contenant des évolutions mineures et la version 2.0 qui refond l’architecture du logiciel – est une très bonne chose, encore faut-il les créer à bon escient et savoir effectuer les merge en bout de ligne.

Par conséquent, de même qu’un outil résolvant un problème ne se posant pas est contre-productif, un outil que l’équipe n’est pas assez mature ou organisée pour utiliser correctement est plus dangereux que l’absence d’outil.

Pour paraphraser Jean Bodin, il n’est d’outil que d’homme.