La Faute se cache dans la détails. La coïncidence des faits. Plusieurs fenêtres, des petit carrés noirs éclairés de pattes de mouches, lire, chercher les traces et reconstituer ce qu’il peut bien se passer, sans penser à mal, sans rien préjuger. Les éléments jouent ensemble pour se jouer du tout. Qu’est-ce qui se passe, dans la réalité? Pourquoi lorsque je demande un bouquet de fleurs ma requête n’aboutit pas? Contrairement à la vie, un programme informatique suit un ordre précis, ligne à ligne, une logique implacable et qui pourtant à la fin se perd dans des limbes. Relire, encore, pour trouver le coupable. Cela demande de l’empathie. Se mettre à la place de la machine. D’abord il reçoit la requête. Il ne fait pas de doute sur sa bonne réception, il ne sait pas mentir pas, il ne sait pas jouer et je ne dois pas me formaliser de son inaptitude chronique à ne pas faire ce qu’il dit qu’il fera, il ne cherche pas à nuire, ni à servir, il fait jouer sa mécanique sans penser. Je ne dois pas chercher à l’accuser mais à montrer sa faute. Il est tout de suite au travail, je le vois, je piste chacune de ses actions. Il regarde ce qu’il lui reste en stock, il compte chaque fleur pour reconstituer par avance le bouquet espéré et il se rend bien compte que cette demande est raisonnable, il doit agir sans attendre. Il écrit la commande dans un journal. Puis il demande un service à la banque puis n’attend pas la réponse obtenu - c’est un autre que lui même qui s’en chargera, un clone, une autre fenêtre de code, plus tard. Il sait juste que l’action arrivera, qu’on prendra note de la réponse de la banque, on décidera, on acceptera ou pas et renverra une réponse, car c’est écrit. La banque a répondu, il le sait, l’autre doit demander la préparation du bouquet et sans attendre peut enfin répondre: Oui votre bouquet sera livré. Et pourtant non. Non. J’essaie et pourtant oui, mais non, car c’est la réalité, pas pour tous les bouquets, certains disparaissent, certains ne sont jamais envoyés. Je lis et relis le journal, le programme, les actions. La logique est respectée, si on était dans un monde parfait jamais un bouquet ne serait oublié. Il faut mettre en doute. Ouvrir une fenêtre derrière chaque fenêtre - deviner, éclairer, recommencer. Les fleurs sont là. La banque prend l’argent. Le bouquet n’est pas envoyé. Le hasard? Cela n’existe pas. Mais la coïncidence, oui. La mécanique grippée. Pourquoi rien ne va alors que tout marche? Il ne reste plus qu’une seule faute possible. Il écrit, il écrit trop, il a trop écrit. Son journal est rempli, il ne peut plus prendre de notes du tout, il s’arrête, sa mémoire est pleine, de trop de lignes, trop d’actions répétées. Fuck la banque. Fuck le bouquet. Tout va bien, il a juste tout abandonné.

Codicille. Définition: The facade pattern (also spelled façade) is a software-design pattern commonly used in object-oriented programming. Analogous to a facade in architecture, a facade is an object that serves as a front-facing interface masking more complex underlying or structural code. (…) Developers often use the facade design pattern when a system is very complex or difficult to understand because the system has many interdependent classes or because its source code is unavailable. This pattern hides the complexities of the larger system and provides a simpler interface to the client.

https://en.wikipedia.org/wiki/Facade_pattern

Faire une Façade est un modèle de conception communément utilisé lorsque l’on programme avec des objets. Analogue à la façade d’un bâtiment, une façade est un objet qui sert à cacher une certaine complexité dans le programme. Les développeurs créent souvent des façades lorsqu’il y a trop d’interdépendances ou lorsque le comportement initial est refoulé, caché, secret. Cette manière de faire cache la complexité des plus importantes mécaniques en jeu et fournit aux personnes une manière de communiquer plus acceptable.