La semaine dernière, c'est Cyrille Martraire qui nous parle de bonnes (et de mauvaises) manières pour modéliser les domaines métier, dans l'objectif de découvrir les principes premiers de ces domaines… et ensuite les remettre en cause. Pour cela, les développeurs et les développeuses doivent pouvoir proposer des abstractions qui permettent de généraliser ce que les spécifications n'ont décrit que dans quelques cas particuliers.
Lundi, c'est Peggy Avez qui, dans ses après-midis de Simone, nous donne à lire Le Désordre Philosophique de Barbara Cassin. Elle nous parle de la part féminine de la philosophie : c'est ce qui reste une fois que les philosophes hommes ont conceptualisé. (Je parle ici de philosophie dans le sens universitaire du terme, ce qui fait qu'on peut se faire appeler philosophe dans les rayons des librairies ou sur France Culture).
Cyrille Martraire demande aux développeurs et développeuses de ne pas être de simples compilateurs de spécifications humains. Pour cela, il propose de remonter la waterline, la ligne qui sépare ce qui est du ressort de la conception, le « comment », le design, de ce qui est du ressort du besoin, le « quoi », les requirements. Remonter cette ligne, c'est trouver les abstractions dans lesquelles presque tous les cas métiers rentrent. Ensuite, ces abstractions vont pouvoir être étendues, prolongées, vont pouvoir opérer, pour s'élargir à d'autres cas métiers non encore décrits mais qui s'avéreront justes par la suite. L'exemple donné dans la présentation me parle : on a déduit l'existence des quarks à partir du comportement des particules élémentaires connues (proton, neutrons…), puis on a recombiné par la pensée ces quarks, ce qui nous aurait permis d'imaginer de nouvelles particules qu'il nous restait juste à découvrir.
Du côté de Barbara Cassin, je retiens de cette part féminine de la philosophie qu'elle a du mal à être exprimée de manière concise. Et c'est logique en fait, puisque par nature c'est ce qui reste une fois les concepts mis de côté. Ma mémoire transforme, mais les images qui me restent pour décrire cette part féminine parlent de ce qui colle encore au réel, un peu comme les marques que laisserait la vérité dans le réel, après qu'on l'eut extraite dans des concepts. Et ces marques, il ne faut surtout pas les jeter après les avoir grattées, au contraire, ce sont elles qui permettront de mieux penser, de penser plus fin. Ces marques, c'est donc ce qui ne rentre pas dans la théorie : c'est ce qu'on a dû laisser en dehors des livres. C'est finalement ce qui délimite les frontières contre lesquelles la Philosophie Occidentale a pu s'appuyer et se construire, mais sans les inclure. (J'entends par Philosophie Occidentale cette lignée de penseurs curieusement exclusivement masculins qui part des grecs classiques, pour le dire vite). Ainsi, c'est ce qui reste de la pensée quand elle ne Philosophe plus. Philosopher avec un grand p comme patriarcal, c'est-à-dire que seuls les hommes ont le droit de produire.
(Je retrouvais aussi, dans cette part féminine de la philosophie, dans cette volonté d'accommoder les restes, une part de ce que j'ai retenu de l'éthique du Care de Carol Gilligan. Sans rentrer dans le détail, je résumerais comme cela : la société érige à son sommet la Loi, représentée par l'homme de justice. Mais cette construction, promue par les hommes, laisse aux femmes le soin d'adapter discrètement la justice au réel : ce sont elles qui y intègrent les contraintes relationnelles, ou qui prennent en compte l'attention que l'on doit aux autres, permettant alors que la vie puisse se déployer dans cet univers, certes juste, mais néanmoins stérile. Et elles le font souvent en marge de la loi.)
Et alors je reprends le point pivot de la présentation de Cyrille Martraire, quand il demande aux développeurs et aux développeuses de remonter aux abstractions dans lesquelles presque tous les cas métiers rentrent. C'est dans ce « presque » qu'il rencontre Barbara Cassin.
Et il propose de donner à ce « presque » toute sa place : être un bon développeur ou une bonne développeuse, c'est justement laisser la place à ce qui ne rentrera pas dans les abstractions, ce qui est hors-modèle. C'est prendre soin des exclus. Techniquement, c'est aller chercher la valeur dans le bon traitement des exceptions. C'est aussi donner la possibilité de déclencher des débrayages, c'est-à-dire des traitements manuels quand le process prévu ne s'applique pas, des voies de contournement officielles, documentées, indolores. Ainsi, une fois le domaine modélisé, si on attend que celui-ci se réduise à un petit ensemble de règles, alors il y aura un ensemble d'exceptions ; et Cyrille Martraire avance que ces exceptions prendront dans le système à peu près autant de place que les règles, qui elles couvrent pourtant l'immense majorité des cas. On apprend ensuite à implémenter ces exceptions derrière une interface (interface qui n'expose que le contrat collant à l'abstraction). Par-là, on protège ces exceptions autant qu'on s'en protège. Et c'est, pour moi, là que se trouvent les vrais bugs. Je ne parle pas des bugs dus à l'ignorance de la personne qui a codé, à la pression, au manque de communication. Mais des bugs de modèles, ces bugs qui représentent l'imperfection humaine, l'écart à la théorie.
Ainsi, la critique de Barbarin Cassin remet en cause l'absolu philosophique classique, en exhibant de la matière pensante en dehors de la recherche de la vérité par la raison. De même, l'éthique du Care remet en cause l'absolu de la justice. Alors, de manière similaire (mais plus trivialement), il faut accepter que la plupart des systèmes d'information ne puissent pas présupposer d'une vérité architecturale ou fonctionnelle. Non, il n'y a pas d'architecture parfaite. Non, il n'y a pas d'expert pouvant modéliser parfaitement la réalité.
Il faut au contraire construire des architectures informatiques qui laissent place au non-encore-exprimé autant qu'au non-exprimable. Jouissons, soit ! de la découverte d'un concept générique, mais apprenons tout autant à prendre soin de toutes ses exceptions.
Je pense donc je blogue
