La mètis du développeur

La mètis est notamment la ruse qui permet de surmonter une difficulté, de passer un obstacle, de renverser une situation délicate ou désavantageuse.

Le premier exemple cité est celui d'Antiloque qui doit participer à une course de chars muni de chevaux moins rapides que ceux de son concurrent, Ménélas. La situation lui est donc nettement défavorable, mais son père Nestor lui indique une ruse: faire une queue de poisson à Ménélas pour forcer le passage en tête. Grâce à cette ruse, Antiloque remporte la victoire, une victoire qui semblait pourtant acquise à son concurrent.

On remarque en passant que celui qui fait l'action n'est pas celui qui en a l'idée: Antiloque n'est que l'exécutant de la ruse conseillée par son père. D'autre part, il n'est pas question d'improvisation: la course et la queue de poisson sont préparées, pensées avant qu'elles n'aient lieu. Enfin, Antiloque doit être sur ses gardes pour saisir l'occasion, le kairós, le bon moment pour faire son action.

L'exemple qui m'a le plus marqué est l'épisode des argonautiques attribués à Orphée, lorsque les Argonautes doivent franchir les Roches Cyanées, "deux masses de pierre qui se confondent et se disjoingnent dans un mouvement alternatif" (p. 208). Le but de la manoeuvre est de passer au bon moment pour éviter que le navire ne soit broyé.

Dans cet épisode, un oiseau envoyé par Athéna guette le bon moment pour franchir le passage, "Quand enfin il s'élance, les deux roches, qui se sont séparées, reviennent l'une vers l'autre, assez vite pour sectionner l'extrémité de sa queue, mais pas assez pour l'empêcher de gagner le Pont Saint-Euxin. A sa suite et à son exemple, les Argonautes s'engagent sur la même route, ils échappent eux aussi à la prise des roches qui, définitivement vaincues, se fixent et s'enracinent dans la mer." (p. 208)

La mètis permet aux argonautes, en observant l'oiseau et en agissant au bon moment, de franchir l'obstacle. Mieux encore, les roches vaincues s'étant immobilisées, une nouvelle voie est ouverte, une voie que d'autres peuvent alors emprunter, un passage.

Dans ce récit, je vois une analogie au travail du développeur qui souvent procède de la même façon: d'abord observer, puis imaginer une façon de surmonter le problème rencontré, enfin essayer une solution qui, si elle est couronnée de succès, ouvre le passage, ouvre la voie vers la suite du développement. L'obstacle rencontré n'en est plus un. L'oiseau symbolise l'idée que l'on se fait de la solution, et une fois qu'elle semble marcher "dans la tête", on l'essaie.

Ulysse est le héros à mètis par excellence, le "pólumètis", "aux ruses variées". Dans l'Odyssée, il n'a de cesse de surmonter les obstacles qui se mettent en travers du chemin de son retour vers Pénélope. Sa mètis lui permet chaque fois de trouver un "expédient" pour passer ces obstacles.

Le développement d'un logiciel s'apparente parfois à une Odyssée: Le but à atteindre est connu, mais les difficultés apparaissent au fur et à mesure de la progression, et la première version d'un logiciel se compose souvent d'une suite d'expédients pour résoudre ces problèmes et obtenir un premier prototype. Au moment où le développeur pense toucher au but, il n'est pas rare qu'une nouvelle difficulté se présente, d'où la règle bien connue selon laquelle les derniers 20% d'un logiciel prennent 80% du temps. Une petite pensée pour Ulysse qui pensait rentrer chez lui rapidement mais qui mit tout de même plusieurs années pour cela... Une façon supplémentaire d'expliquer que le temps de développement d'un logiciel ne peut être connu à l'avance.

Chaque résolution de problème sur le chemin contribue à ouvrir la voie vers le but visé. En profitant de cette voie, c'est-à-dire de la connaissance et de la compréhension acquises durant la première version, le développeur peut plus facilement développer une seconde version, plus élégante par le fait que cette dernière ne sera pas une suite de réponses à chaque problème, mais une réponse globale répondant à tous les problèmes rencontrés. On peut y voir en un certain sens la distinction entre Hermès qui fraie des chemins et Apollon qui construit des routes, si j'ai bien suivi C. Fauré.

Détienne et Vernant décrivent également le Póntos:

Le développement logiciel ressemble bien à la tentative de franchir le Póntos, comme une avancée sur une mer inconnue. La mètis du développeur l'aide à franchir les obstacles, mais encore faut-il un tékmar, un repère, sinon le Póntos demeure infranchissable. Ce repère, c'est ce que le développeur vise, ce qu'il poursuit, l'idée qu'il se fait du résultat final de son développement. Sans repère, le développeur ne peut naviguer.

De plus, c'est d'un repère relativement fixe dont le développeur a besoin. Voyons pourquoi.

Détienne et Vernant indiquent que le chemin et le lien partagent en quelque sorte le même sens, ce que C. Fauré relève:

C. Fauré explique que Google, en même temps qu'elle produit des routes sur le web, lie en même temps ses utilisateurs, les chemins sont aussi les liens.

Il en va de même dans le développement d'un logiciel: les chemins tracés par le développeur au fur et à mesure du développement sont autant de liens. Les chemins qu'a pris le développeur en s'orientant par les repères lui permettant de viser son but, ont imprimé cette orientation dans le logiciel, en terme de potentiel d'évolution selon certaines directions (comme j'ai eu l'occasion de l'écrire ici). Ces chemins sont donc aussi des liens qui entravent le développement du logiciel vers d'autres directions.

Lorsque le développeur navigue sans repère fixe, comme s'il visait toujours le soleil, les chemins, les liens qu'il fabrique finissent par rendre toute modification du logiciel impossible: tous les chemins sont enchevêtrés, le développement ne peut plus aller dans aucune direction, le logiciel est complètement lié et finit par ressembler au Tartare, et le développeur se retrouve dans l'embarras, dans l'aporie à laquelle il tend pourtant toujours à échapper.

Il m'est déjà arrivé d'avoir à reprendre un logiciel et d'avoir le sentiment que tout partait dans toutes les directions. C'est souvent le cas lorsque plusieurs développeurs en CDD se sont succédés sans même partager une vision commune, c'est-à-dire quelques repères commun.

Mais... une minute ! Le code écrit, grâce à l'intelligence rusée du développeur, l'a été pour résoudre un problème à un moment donné, pour surmonter un obstacle, à la manière dont le navire Argo passait les Roches Cyanées. Mais c'est maintenant ce même code qui constitue l'un des liens qui bloquent le développement du logiciel ?

En effet. Lorqu'un morceau de code est écrit, il l'est pour résoudre un problème, c'est-à-dire sortir d'une situation de blocage, même minime. On peut dire que ce qui était lié est délié, ou plutôt que le logiciel a pu s'échapper de ses liens pour continuer d'être développé, que le développeur a échappé à l'aporie. Mais ce faisant, comme tout chemin, ce morceau de code est aussi un nouveau lien. Un lien qui lie le logiciel et entrave son potentiel d'évolution dans certaines directions.

C'est le côté pharmacologique du code, comme tout object technique: à la fois remêde et poison.

A ce point,il conviendrait de visionner de la conférence de Bernard Stiegler "La société automatique" (à partir par exemple de 16'54" mais mieux vaut tout visionner) :

Pour résumer grossièrement, le côté toxique de la technique, en tant qu'il produit une hétéronomie, qui stoppe l'individuation et brise les circuits de transindividuation, ne doit pas être nié. Au contraire, il est même la condition pour la production d'une nouvelle autonomie, une possibilité de penser par soi-même (oui, bon, j'ai du mal à résumer, mieux vaut regarder la vidéo).

Appliqué à notre problème, cela signifie qu'un logiciel lorsqu'il devient, sous l'effet de la toxicité du code, complètement lié, place le développeur dans l'impossiblité de s'individuer en développant le logiciel, puisque ce dernier ne peut plus l'être. Le développeur ne peut plus apprendre en développant le logiciel, il a donc perdu en autonomie.

Il faut alors tirer parti de ce blocage, de cette aporie, pour apprendre à nouveau: pourquoi est-ce bloqué ? quelles erreurs ai-je commises ? le problème à résoudre était-il en fait mal posé et donc la solution implémentée inadaptée ? C'est le moment de l'épochè.

En général, le développeur n'aime pas que son code marche du premier coup (en tout cas moi je n'aime pas, je préfère rencontrer quelques problèmes). Dans ce cas, il n'a rien appris. Au contraire, un code qui ne marche pas questionne le développeur, lui permet de mieux comprendre un problème qui paraissait pourtant simple.

Evidemment, le développeur ne passe pas son temps à être bloqué, le morceau de code qu'il produit ne devient pas tout de suite toxique.

L'un des aspects du développement logiciel est même de faire en sorte que certaines parties du code deviennent toxiques, bloquantes, entravantes, le plus tard possible. La modularité, la généricité ou encore le paramètrage sont des techniques qui vont dans ce sens. C'est particulièrement important concernant les APIs: il ne s'agit pas qu'elles changent tous les quatre matins, sans quoi tout ce qui les utilise devrait également être mis à jour. Les APIs sont donc des liens très forts, et on a envie qu'ils soient le plus lâches possible.

La mètis est encore ce qui permet au développeur d'anticiper le futur, les besoins, et donc de produire du code qui durera plus longtemps.

En effet, la mètis est aussi associée à la prudence. Détienne et Vernant parlent ainsi de la mètis du politique,

La mètis du développeur lui sert donc à agir pour surmonter les problèmes présents mais aussi à anticiper les problèmes futurs. Tous les développeurs connaissent cette tension: agir ou coder tout de suite sans beaucoup réfléchir, ou réfléchir sans jamais commencer à agir ou coder. Tout est dans la mesure entre les deux, selon chacun, son expérience, parfois même son impatience ou sa patience (et malheureusement pour beaucoup de développeurs, selon les délais imposés par le marché). Les deux ne s'opposent pas mais se nourrissent l'un de l'autre: il faut coder pour tomber sur des problèmes auxquels on n'avait pas pensé, et il faut réfléchir pour savoir quoi coder, de façon à ce que ce code reste valable pour un horizon de possibles assez large.

C'est aussi grâce à cet aspect de la mètis que le développeur n'optimise pas trop tôt, car, comme dit Donald Knuth, "l'optimisation prématurée est la racine de tous les maux¹. Lorsqu'il optimise une partie de son code, le développeur sent bien qu'il enferme une partie de son logiciel, qu'il en diminue le potentiel d'évolution, qu'il se résigne à figer cette partie. Je parle ici d'optimisation au sens de spécialisation; il arrive qu'on change un logiciel pour gagner en performance mais simplement en posant le problème différemment pour trouver une solution plus performante, sans pour autant obérer l'avenir de cette partie.

En général, j'optimise les parties que je pense ne pas être celles les plus susceptibles d'évoluer par la suite. Mais quand il est nécessaire d'optimiser une partie non stable, j'essaie de modulariser, afin de circonscrire la partie figée, ces liens qui sinon se déploieraient dans tout le logiciel.