Modèles, algorithmes, tout ça

Pour faire suite aux commentaires d'Eglantine dans le billet précédent, je vais essayer de détailler comment je vois l'articulation modèle/algorithme.

Disons tout d'abord qu'un algorithme peut être vu comme un moyen de passer d'une catégorisation à une autre, ou de transformer de l'information en entrée en une information en sortie. En sortie, l'information ne peut pas être plus riche qu'en entrée. Cependant l'algorithme peut permettre de la présenter différemment, ou de la faire "apparaître" car elle était présente en entrée mais pas bien visible, appréhendable.

Nous avons alors plusieurs possibilités:

• Soit on cherche à obtenir une information en sortie, en connaissant les moyens de transformation (les algorithmes) à notre disposition permettant de l'obtenir, alors on peut inférer l'information dont nous avons besoin en entrée,
• Soit on connaît l'information en entrée et, connaissant tout ce qu'il est possible de faire comme calculs dessus, on peut savoir quelle information ou catégorisation on peut obtenir en sortie, moyennant un certain agencement des transformations possibles,
• Soit on veut obtenir une information ou une catégorisation en sortie mais on ne connaît pas de chemin, de méthode, d'algorithme pour l'obtenir. Il faut chercher ce chemin pour connaître l'information suffisante dont on a besoin en entrée.

Le dernier cas se rapproche de la recherche en mathématique: on souhaite prouver une propriété sur des objets, mais on doit pour cela poser des hypothèses plus ou moins fortes, permettant d'appliquer des théorèmes déjà connus afin d'en bâtir un nouveau.

Quand j'écrivais dans le billet précédent que "L'algorithme n'est qu'une conséquence du modèle", je me plaçais dans le second cas, celui où j'ai un modèle en entrée, dont je veux extraire une catégorisation. Ce modèle en entrée étant fixé, la meilleure façon d'atteindre la catégorisation voulue en découle d'une certaine façon.

Enfin, le premier cas est le plus courant: on cherche à calculer quelque chose, et au fur et à mesure qu'on cherche un algorithme pour le faire, on se rend compte de l'information qu'il est nécessaire d'avoir en entrée, voire sa forme pour avoir une implémentation efficace.

On pourrait donc dire qu'avoir un modèle en entrée contraint les algorithmes possibles, tandis qu'un algorithme, par les hypothèses qu'il impose d'être vérifiées¹ et les entrées attendues, peut remettre en question le modèle en entrée. On peut le voir comme si l'algorithme mettait des contraintes sur le modèle en entrée, mais rappelons-nous que l'algorithme n'est là que pour produire le modèle en sortie. C'est donc plutôt la catégorisation attendue qui, via les algorithmes connus ou à trouver, contraint le modèle en entrée. En gros, on doit avoir assez d'information en entrée pour en extraire ce que l'on attend en sortie.

Par exemple, si je souhaite avoir l'âge d'une personne, soit je l'ai déjà, soit j'ai besoin de sa date de naissance et de la date du jour. L'algorithme consiste simplement à faire une différence entre ces deux dates. C'est la définition même de l'âge, je connais l'algorithme, je peux donc déduire l'information dont j'ai besoin en entrée. C'est bien la catégorisation voulue en sortie qui implique celle en entrée.

Si maintenant je pars d'un modèle en entrée qui est fixe et qui ne contient pas la date de naissance, je peux peut-être, si j'ai une base de données de fréquences des prénoms par année de naissance, calculer une probabilité d'âge en sortie, qui serait peut-être suffisante pour la catégorisation voulue. Dans ce cas l'algorithme à utiliser est une conséquence de ce qui est disponible en entrée.

Dans les faits, on a un aspect fractal, chaque algorithme faisant appel à d'autres alogrithmes, aboutissant à une chaîne de transformation de l'information; on peut donc être dans l'une ou l'autre de ces situations à différents moments. Pour refaire le lien avec les mathématiques, parfois on cherchera à déduire des choses depuis des hypothèses, pour voir si ce qu'on obtient ne pourrait pas avancer vers le but à prouver, parfois on "remontera" depuis ce que l'on veut prouver pour par exemple avoir à prouver trois choses plus simples.

J'ai jusqu'ici soigneusement évité de préciser ce que j'entends par "modèle".

Commençons par rappeler qu'un modèle est toujours "faux" lorsqu'il s'agit de représenter le monde. Ce n'est qu'une abstraction permettant de faire des calculs pour obtenir une autre abstraction.

Je suis assez d'accord avec la possibilité d'une chaîne de modèles (épistémologique, mathématique, de données) comme indiqué par Eglantine, mais:

• il n'y a pas toujours de tels modèles, en tout cas explicitement,
• il y a des allers-retours, par exemple le couple modèle mathématique / modèle de données évolue un peu à la manière du couple science et technique: chacun remet en cause l'autre, le questionne, le fait évoluer.

La discussion a débuté sur les algorithmes du type de ceux utilisés en profilage, etc., donc des modèles statistiques. Mais les logiciels sont composés d'une foule d'autres aspects (interface utilisateur, entrées/sorties, parallélisme, ...) qui sont rarement formalisés suivant une telle chaîne. Ils sont souvent dans la tête des concepteurs/développeurs, dans la culture d'une communauté autour d'un langage de programmation, voire dans la culture de développement logiciel en général.

Même dans le cas où une telle chaîne existe, souvent pour le "cœur" du logiciel, avec une formalisation, il y a toujours du non-dit qui se rajoute, notamment une vision du futur, des évolutions possibles/probables.

Dans mon expérience, ces non-dits se matérialisent dans la structuration des données: On va choisir telle structure ou tel encodage plutôt qu'un autre parce que ça pourrait permettre telle évolution non encore décidée mais qu'on peut "sentir" comme un prolongement du modèle actuel².

Donc oui, il y a bien une dé-sémentisation lors du calcul et une re-sémentisation pour interprêter le résultat, mais au niveau du code saisi par l'humain, on est encore dans la sémantique, celle-ci ne disparaissant que lors de la compilation vers le langage machine³.

Il y a de l'humain dans le logiciel bien au-delà du modèle théorique, jusqu'au moment où la machine prend la main et qu'elle jette le sens du logiciel pour le transformer en programme exécutable.