Ces quelques réflexions me sont inspirées par ma participation à l'atelier de Agile Alliance sur les outils de test fonctionnel qui a eu lieu lundi 4 août à Toronto, avant le démarrage officiel de la conférence Agile 2008. Elles sont aussi sous-tendues par mon expérience globalement assez malheureuse de mise en place d'outils et méthodes de test fonctionnel d'applications sur différents projets. Elles sont enfin appuyées sur ma réflexion personnelle quant au domaine qui me passionne et m'occupe, la réalisation de logiciels, les problèmes que celui-ci pose et comment ces problèmes sont aussi des problèmes de langages, et ce que les théories contemporaines, modernes ou post-modernes sur le langage et l'épistémologie ont à dire sur la question.
L'agilisme - osons le néologisme - est fondamentalement basé sur l'idée que le seul objet nécessaire et suffisant dans le processus de construction d'un logiciel est son code source. Tout autre sous-produit du processus de développement est soit redondant - il duplique une information déjà contenue ou qui pourrait être contenue dans du code source; soit contradictoire - il contient de l'information qui entre en conflit ou invalide une information contenue réellement ou virtuellement dans le code source; soit hors-sujet - il contient de l'information qui n'a rien à voir avec le logiciel produit, ou qui ne pourra jamais être transcrite dans son code source.
Exit donc l'ensemble des documents habituellement attachés au logiciel: cahier des charges, spécifications fonctionnelles générales, spécifications fonctionnelles détaillées, dossier d'architecture applicative, dossier d'architecture technique, jeux et plans de test, dossier de conception, modèles, diagrammes, livres blancs...
Cependant, reconnaissant le fait que les gens sont plus importants que les outils et sous la nécessité d'une communication efficace, l'agilisme pratique la production d'information secondaire jetable, de préférence utilisant des technologies simples voire primitives: cartes en bristol pour les user stories, tableaux blancs et noirs, post-its, diagrammes informels au papier-crayon...
Mais comme les méthodes "traditionnelles", l'agilisme se trouve confronté au janus bifrons de la correction: le logiciel est-il bon ? est-ce le bon logiciel ? Autrement dit, le logiciel contient-il des erreurs et répond-il aux besoins de l'utilisateur (du client, du donneur d'ordre, de la maîtrise d'ouvrage) ?
A ces deux questions, l'agilisme apporte une seule et même réponse: les tests automatisés. Le code source du logiciel comprend, à côté du code de production implantant les services rendus par le logiciel, un ensemble de tests - unitaires, d'intégration, fonctionnels - qui permettent de répondre automatiquement à ces deux questions en exécutant le logiciel dans un environnement contrôlé.
Bien sûr, ceci suppose que les tests expriment effectivement le service devant être rendu - le besoin. On voit bien que déjà le problème n'est pas résolu mais déplacé: comment savoir si les tests sont bien nécessaires et suffisants pour s'assurer de la correction attendue du logiciel et de sa validité ? L'agilisme répond là encore: c'est le chef de produit (le product owner) qui est propriétaire des tests - sous entendu d'acceptation - et c'est lui qui garantit - avec l'aide de toute l'équipe - qu'ils couvrent bien les spécifications du logiciel.
Cette couverture peut être évaluée et validée si les tests sont exprimés dans un langage compréhensible par le chef de produit, les experts métiers, le représentant du client faisant partie de l'équipe... D'où la nécessité de disposer d'outils permettant une telle expression dont les plus connus aujourd'hui ont pour nom Fit/FitNesse, Selenium, Concordion, GreenPepper, StoryTesting IQ, RobotFramework, Abbot et bien d'autres.
Idéalement, les tests d'acceptation sont définis ex ante avant même que le logiciel ne soit exécutable, et au besoin un analyse métier va aider à compléter leur définition pour identifier et traiter les cas limites, les "trous" dans les tests, les incohérences. Le test est donc ni plus ni moins qu'une spécification exécutable
Mais alors, n'y-a-t'il pas là une contradiction avec le principe premier de l'agilisme qui est de supprimer tout sous-produit - et partant tout travail ou pour employer un terme à la mode tout déchet qui ne contribuerait pas directement à produire du code pour le logiciel ? N'y-a-t'il pas un risque de réintroduire subrepticement de la "cascade" en voulant produire une spécification qui soit consistante et complète avant de développer ? Car un ensemble de tests utilisé comme critère de validation unique qui serait inconsistant ou incomplet serait fort peu utile, voire même dangereux.
Pour éviter cet écueil, l'agilisme introduit deux nouveaux outils: le test - d'acceptation - se transmue en exemple et le processus de validation est complété par le test exploratoire. Ce qui distingue l'exemple du test, c'est qu'il n'a pas vocation à être complet, ni même consistant avec tous les autres exemples au sein d'un système. Comme son nom l'indique, il sert à illustrer, dans un langage compréhensible par toutes les parties en présence, le comportement attendu. Un ensemble d'exemple n'est pas une spécification et n'a pas vocation à le devenir. Au delà de la finasserie sémiologique, substituer la notion d'exemple à celle de test enlève de ces derniers le poids de valider le système effectivement réalisé.
Ce poids se trouve-t-il transféré sur les épaules du testeur par la pratique du test exploratoire ? On pourrait le croire, mais de fait ce n'est pas le cas. Le test exploratoire, comme son nom là encore l'indique, explore le système produit - ce qui soit dit en passant suppose que le système existe et soit opérationnel - mais il ne le cartographie pas. Il va chercher l'eldorado dans les recoins les plus éloignés du système, va prendre les chemins de traverse dans l'espoir de détecter des problèmes ou des incohérences, des comportements non prévus ou gênants, mais il ne le fera pas systématiquement pour l'ensemble des fonctionnalités du logiciel comme aurait vocation à le faire des jeux et plans de test; et il ne le fera pas de manière répétitive et reproductible. Le test exploratoire est, selon la définition usuelle (voir Lessons in Software Testing, Bach, Kaner et al.) une technique d'exploration et d'apprentissage requérant l'intelligence et la connaissance du testeur aux fins d'identifier des erreurs et pannes possibles.
Il faut se rendre donc à la conclusion nécessaire: l'agilisme n'offre aucune solution formelle au problème de la validation du logiciel; il n'offre pas de réponse toute faite à la question: est-ce bien le bon logiciel que nous produisons ? La réponse à cette question est à chercher dans le processus de développement, dans l'intégration d'un utilisateur ou client - ou de son représentant dûment mandaté et effectivement représentatif ce qui est déjà un problème en soi - au sein de l'équipe de développement, dans les interactions permanentes de celui-ci avec les autres membres de l'équipe, dans sa capacité à orienter le développement dans le sens nécessaire, voire le réorienter si besoin est.
S'il n'y a pas de procédure de validation possible, c'est parce qu'une telle procédure suppose l'existence de trois entités disjointes: une spécification, une réalisation concrète de cette spécification et une application surjective de l'un dans l'autre, c'est-à-dire une fonction totale telle que tout élément de la réalisation soit l'image par l'application d'un élément de la spécification (on notera au passage qu'il n'est pas impossible qu'un même élément du logiciel réalise deux ou plus fonctionnalités de la spécification). Autrement dit, on sait dire si et comment chaque fonctionnalité est implantée correctement par le logiciel.
L'entité la plus évidente de ce triangle amoureux est bien évidemment le logiciel lui-même. Il existe, il fonctionne - bien on l'espère, on peut le "toucher", l'exécuter sur une machine idoine, le modifier éventuellement... C'est le produit essentiel du processus de développement. Sa représentation la plus fidèle et la plus compréhensible est son code source - étant entendu que ce terme regroupe toute la matière première nécessaire à la fabrication et l'exécution du dit logiciel sur une machine cible: fichiers de configuration, images et ressources binaires, descripteurs d'assemblages, et non seulement les fichiers source du langage principalement utilisé par le logiciel. Bref, le logiciel exprime dans un - ou plusieurs - langage un processus arbitrairement complexe, à charge pour la machine d'interpréter - correctement - ce langage: en bref, c'est un discours
La spécification est aussi et nécessairement un discours mais exprimé dans un autre langage. Nécessairement car elle a pour but d'exprimer quelque chose, de porter un sens, en l'occurrence les besoins ou exigences auxquels doit répondre le logiciel, besoins que l'ont peut résumer comme des services que doit rendre le logiciel produit, ce qui englobe les notions de besoins fonctionnels et non-fonctionnels, distinction quelque peu arbitraire et surannée. Ce discours est exprimé dans un langage différent de celui de l'implantation et non technique: ce dernier définit le comment tandis que la spécification exprime le quoi du système à produire; nécessairement différent car sinon, il y aurait équivalence entre spécification et implantation et la validation serait simultanément immédiate et totalement tautologique, ce serait la fonction identité
De la nature de l'implantation et de la spécification comme deux discours, il découle que l'application de validation prend la forme d'une traduction de l'un dans l'autre. Cette traduction peut se faire dans deux directions: de S vers I ou de I vers S; et elle peut être automatique ou manuelle.
Si la traduction est automatique, alors cela signifie que les deux langages utilisés sont interprétables par une machine, qu'il s'agit de deux langages de programmation différents mais partageant la nature fondamentale de tous les langages de programmation d'être à un certain niveau identiquement expressifs: chacun d'entre eux peut être ramené à - ie. traduit en - une machine de Turing. En supposant que cette traduction, de S vers I, soit toujours possible ou au moins qu'elle le soit dans tous les cas qui nous intéressent, on se trouve confronté à la question de l'utilité d'exprimer la même chose sous deux formes différentes: si l'on est capable d'exprimer le comportement d'un logiciel dans un langage A plus compréhensible et plus concis que B, alors pourquoi faire deux fois le travail ? La seule réponse correcte est que l'on obtient ainsi deux sources de légitimité qui se valident l'une l'autre, de la même manière qu'une démocratie fonctionne en instituant des contre-pouvoirs pour chaque pouvoir, au prix d'un travail supplémentaire et toujours recommencé de légitimation croisée des différents pouvoirs.
Cette voie peut prendre la forme des méthodes formelles telles que B, Z, VDM, dans lesquelles une spécification est progressivement raffinée en une implantation par un processus complexe de preuve dans lequel chaque étape est plus précise et détaillée que la suivante, et prouve que l'introduction de ces détails respecte les contraintes définis au niveau précédent. La traduction se fait ici de S vers I, elle est nécessairement correcte pour autant que les preuves accumulées soient correctes.
Les méthodes d'ingénierie dirigée par les modèles rentrent dans cette même catégorie. L'utilisation d'une notation graphique (eg. UML) semble plus aimable, moins agressive qu'une notation mathématique purement symbolique, mais il n'en reste pas moins vrai qu'une sémantique formelle doit être attachée à ces diagrammes pour espérer les transformer en code exécutable - source ou binaire importe peu en la matière.
Par sémantique, on entend bien sûr, là encore, une procédure de traduction du langage des diagrammes vers le langage de I qui soit indépendante de S - ie. elle peut s'appliquer sur n'importe quel discours S' dans le même langage. Toute traduction ad hoc est ici disqualifiée: on en arriverait à la nécessité d'écrire trois fois le même logiciel, une fois sous forme d'une spécification, une fois sous forme d'implantation et une fois sous la forme d'un traducteur spécifique de l'un à l'autre.
Elle peut aussi prendre la forme de l'analyse statique ou dynamique du code: interprétation abstraite, model-checking, analyse de flot de données, vérification de contrats (à la JML), mais aussi test à partir de modèles ou encore typechecking. Ici la traduction se fait de I vers S et la difficulté est de s'assurer qu'elle est bien surjective, c'est-à-dire que toute entité de I est interprétable dans S. Dans les cas extrêmes, le processus produit S à partir de I.
Dans les deux cas, les niveaux de langages utilisés sont très proches et les contraintes inhérentes à la calculabilité - et même à la complexité - imposent des limites strictes à ce qu'il est possible d'exprimer et de traduire automatiquement d'un langage vers un autre, donc à ce qu'il est possible de valider.
Traduire de S vers I présente donc in fine deux problèmes:
Toute validation automatique ne pourra des lors être que partielle et nécessitera un niveau de compétence technique au moins équivalent à celui d'un programmeur pour être réellement utile, hormis dans les rares cas où le domaine des fonctionnalités du logiciel sont suffisamment proches des concepts et outils de base de l'informatique pour que les experts du métier, les analystes et les utilisateurs comprennent la langue. Notons que ce problème d'automatisation partielle est pris en compte dans les méthodes formelles par la technique de l'obligation de preuve: lorsque le prouveur achoppe sur une propriété indécidable mécaniquement, il demande à l'utilisateur de le guider et de valider les hypothèses nécessaires à la poursuite du travail de validation.
Pour poursuivre l'analogie avec les langues naturelles, la traduction automatique d'une langue à une autre n'a de chance de produire un résultat significatif que si:
Les tests fonctionnels - ou tests d'acceptation, en tant qu'ils sont un outil de validation automatisé de la spécification souffrent donc des mêmes maux. Ils sont aussi la description dans un langage nécessairement formel puisqu'exécutable par une machine d'une plus ou moins grande partie de la spécification S. Confrontés à l'impossibilité de construire effectivement S, on en produira une image dégradée, appelons là T, un ensemble de tests ou d'exemples supposé offrir une approximation suffisante de S (ie. good enough).
Cette position, tout en prenant acte de l'idéalisme inatteignable des spécificationnistes, n'en rejette pas la prémisse: même si ce n'est que dans l'empyrée des Idées, il existe "quelque chose" qui spécifie ce que le logiciel doit faire, quelque chose que nous ne savons pas réaliser, qui ne s'incarne pas dans un objet, mais que nous pouvons utiliser comme idée, comme guide, comme concept, dont nous pouvons examiner telle ou telle partie pour guider notre travail et la réalisation des tests.
L'agilisme, quoi qu'il en ait, comme toute méthode de développement de logiciel basée en tout ou partie sur un processus de validation du code produit par rapport à une spécification reste fondamentalement essentialistes en tant qu'ils persistent à concevoir l'existence d'une entité externe, d'un étalon, d'une idée donc, dont on cherchera à produire une image la plus fidèle possible dans notre logiciel.
La traduction de S en I nécessaire à la validation du second par le premier peut aussi se faire manuellement, c'est même l'immense majorité des modes de validation pratiqués sur le marché de la production de logiciels. Ici S est exprimée en langage naturel, dans un discours qui peut-être éventuellement oral, voire même ne pas être exprimé du tout et résider dans l'esprit d'un ou plusieurs experts métier
Mais la même prémisse ontologique sous-tend le processus de validation, qu'il soit mécanique ou humain: on présuppose l'existence de S, ici on parlera plutôt de besoins ou mieux d'exigences, pour pouvoir valider I. L'être humain est ici détenteur de S qu'il le veuille ou non et c'est à lui qu'incombera la responsabilité de valider I.
Là encore, cette validation pourra se faire dans les deux sens, de S vers I ou de I vers S. Dans les deux cas est à l'oeuvre une vision mécaniste et plutôt naïve de la production de systèmes ou fragments de systèmes d'informations. Cette vision peut être schématisée comme suit:
Un examen un peu plus détaillé de la réalité et un minimum d'expérience du développement de logiciels et systèmes permet de se rendre compte que les choses ne se passent pas ainsi. Il est rarissime que l'utilisateur/client soit capable de s'exprimer réellement en terme de besoin ou de problème, et encore plus rare qu'il soit capable de décrire les fonctionnalités attendues du logiciel.
La décision de réaliser un logiciel a en fait beaucoup de motivations et d'origines qui n'ont rien à voir avec un quelconque besoin réel: un chef un peu trop informé sur les dernières percées technologiques et sensible à la mode, un concurrent ou un fournisseur trop bavard, un changement de personnel, départs, mutations, arrivées qui perturbe le train-train quotidien, une panne ou un accident inopiné qui oblige à des révisions déchirantes, un commercial sympathique et très convaincant, voire des causes encore moins avouables telles que la pure et simple bêtise, la jalousie, la corruption...
On peut faire sans se tromper l'hypothèse que si la décision de produire un logiciel ou même d'adopter tout changement technologique, voire tout changement, était rationnelle et dépendant de la réalité et de l'analyse détaillée de besoins et de problèmes, nous en serions encore à faire de la comptabilité avec des cailloux ou des noeuds sur des cordes. A titre d'exemple, rappelons les troubles violents suscités par les luddites en Angleterre au début du XIX° siècle lors de l'introduction des premiers métiers à tisser automatiques, les craintes - justifiées - pour leur emploi des ouvriers de l'industrie automobile lors de l'introduction des premiers robots.
Et combien de projets de logiciels sont réalisés sans que ne doivent changer d'un iota l'interface graphique sous peine de perturber les utilisateurs et provoquer des mouvements sociaux allant jusqu'aux grèves.
Exit donc le concept flou, insaisissable et finalement faux de besoin ou d'exigence. Dans la réalité, le logiciel ou système est le résultat d'un processus ou plus précisèment d'un dialogue entre deux - au moins - parties qui n'est pas à sens unique: les besoins exprimés par l'utilisateur informent la réalisation du logiciel autant que celle-ci transforme ceux-là.
Modifier un système d'information ou créer un logiciel, c'est nécessairement modifier la manière de travailler - de jouer, de créer, de conduire... - de ceux qui l'emploient, qu'on le veuille ou non, et ce dans un sens imprévisible, puisque nul n'est capable de prévoir à l'avance quelles sont les caractéristiques d'un outil qui vont "prendre" ni comment ces caractéristiques seront utilisées. Toute innovation technologique est vouée à échapper à son créateur, pour le meilleur et pour le pire: croire le contraire c'est prétendre au statut de démiurge omniscient, avec les conséquences que l'on imagine.
Un processus de développement qui nie ces aspects, qui considère que le logiciel n'est que l'automatisation d'un processus existant, qui prétend que rien d'autre ne change que des mesures de temps, de rentabilité, de productivité quand on introduit un nouveau système, est soit extrêmement naïf, soit extrêmement cynique, soit totalement dénué d'intérêt.
Seule la première hypothèse mériterait les circonstancs atténuantes. Dans les deuxième cas et troisième cas, probablement les plus fréquents, le développeur accepte soit d'être l'acteur d'un jeu de dupe avec les risques d'être soit même la dupe, soit l'ennui profond d'un travail sans enjeu ni perspective.
L'agilisme, au moins en théorie, reconnaît cette réalité et va donc mettre le dialogue au coeur du processus, sous le nom de feedback ou rétroaction. Le système que constitue le processus de développement est une boucle de rétroaction entre deux entités et l'information circule bien dans les deux sens. Pour que ce dialogue soit le plus fructueux possible, il faut qu'il passe par un langage commun: sans langage partagé, pas de dialogue. Ce langage commun c'est justement le système objet du processus de développement.
Un logiciel est donc - doit donc être - un langage au travers duquel les acteurs de sa réalisation et de son utilisation se parlent et sont parlés. Le fait qu'il soit construit progressivement à partir d'autres langages mais en lumière deux caractéristiques essentielles de cet artefact obscur qu'est le langage: d'une part la nature dialogique du sens, d'autre part l'auto-référentialité.
La responsabilité du développement est donc très grande: le développeur collabore avec l'utilisateur pour produire un langage qui parle à ce dernier, mais aussi qui parle de lui. Et cette parole qui se crée est une arme redoutable, elle peut être libératrice mais bien plus souvent aliénante elle se révèle aliénante. Le développeur, à son niveau, se trouve confronté au dilemme crucial qui émerge de La Condition Post-Moderne de Lyotard: participer de la construction d'un nouveau totalitarisme, ou mettre à profit les potentialités de ce nouveau discours pour accroître la connaissance et la création. En raccourci, tout développeur se trouve confronté quotidiennement au dilemme de participer à la création d'Echelon ou à celle de Wikipedia, toutes proportions gardées ! Comme le disait les situationnistes dans les années 60: "Choisit ton camp, camarade !".
Mais rien n'est aussi simple...
Le discours rationaliste précédemment décrit n'est justement que cela, un discours, destiné à justifier aux yeux de celui qui l'émet et de ceux qui le reçoivent des décisions par ailleurs globalement irrationnelles ou en tout cas beaucoup moins claires que l'on ne veut bien se l'avouer. Il fait partie d'un discours plus vaste, celui de la modernité occidentale, du Progrès, de la Raison, de la Science dont on sait depuis le siècle précédent qu'il a ses limites, qu'il n'a pas valeur de vérité universelle pour tous lieux et tous temps, qu'il est lui aussi le produit d'une histoire et d'une idéologie, d'une vision du monde particulière, en l'occurrence bourgeoise et libérale.
Les penseurs dits post-modernes ou post-structuralistes, qu'ils soient philosophes, sociologues, linguistes, psychanalystes, artistes, se sont attachés depuis les années 1960 à déconstruire ce discours, à détricoter ces mailles invisibles qui enserrent notre pensée et notre existence et limitent arbitrairement notre liberté sans même que nous en soyons conscients. On peut noter que ce discours est particulièrement prégnant dans le monde du logiciel depuis ses premiers balbutiements dans les années 1950 et les premières recherches en intelligence artificielle, alors même que les mathématiques ont dès les années 30 et le fameux théorème de Gödel, abandonnées toute prétention universaliste.
On le retrouve alors dans ce grand classique qu'est Gödel-Escher-Bach, dans le programme des méthodes formelles des années 80 et de l'IA des années 60 et 70, dans les ambitions démesurées du MDA, et de manière générale dans toutes les méthodes de développement, dans la croyance qu'il serait possible de modéliser le réel sous la forme d'un logiciel.
On aurait pu croire que l'agilisme échapperait à cette tendance naturelle, qu'il serait une mutation sauvage ayant fait perdre aux informaticiens leur gène totalitaire. Et c'est probablement ce qu'il a été à ses débuts. En remettant l'humain au centre du processus de développement, en supprimant tout ce qui n'est pas le code, en cherchant à maximiser les interactions entre développeurs et utilisateurs de logiciels afin de s'assurer au plus tôt que l'on produit bien le bon logiciel, en instaurant une discipline stricte mais surtout librement consentie dans les pratiques de développement, en généralisant le binômage pour sortir les informaticiens de leur autisme naturel, en construisant une équipe constituée d'individus égaux en droits, unis par un même objectif mais aussi par une même pratique, une même Weltanschauung, enfin et surtout en libéralisant la parole et la communication pour la sortir du carcan technocratique où l'avaient enfermés plusieurs décennies d'informatique pilotée par la technostructure, l'agilisme s'est vécu comme une authentique révolution.
Et comme toute les révolutions, pour réussir elle a du produire un nouveau discours en sus de renverser le discours précédent, tâche à laquelle se sont attelés les pionniers au travers de leurs livres, leurs blogs, leurs discours. Et comme toute les révolutions "réussies", croyant renverser l'institution elle n'a fait que permettre à quelques uns de la rejoindre et à celle-ci de renouveler son discours, de se régénérer en absorber ce nouveau discours.
Le propre de la société spectaculaire est sa capacité à tout recycler en spectacle, c'est-à-dire en marchandise. Et c'est pourquoi voyons désormais fleurir les spécialistes de l'agilité et les certifications - bien entendues payantes, pourquoi de si nombreuses SSII embrassent l'agilisme et récrivent leurs plaquettes en prenant soin de remplacer - ou d'ajouter - CMMI par Scrum et RUP par XP.
Parvenu à ce point du discours, le lecteur patient se pose légitimement la question cruciale: et alors ?
Partant de la question de la validation du logiciel dans l'agilisme, nous sommes parvenus à une critique de celui-ci, constatant que ce qui se présentait initialement comme une révolution est aujourd'hui devenu une tarte à la crême, une méthode comme une autre de développement de logiciels, un élément d'un discours, tout simplement parce que différant sur les détails, il ne remet pas en cause les prémisses fondamentaux de la pensée dominante, c'est-à-dire une position simultanément idéaliste et rationaliste: un logiciel est l'image idéelle d'une spécification et il est possible au moins théoriquement d'approcher d'aussi près que l'on veut cette idée, de la décrire précisèment dans le langage dans le système produit (ie. le langage de l'implantation) de sorte que l'on soit capable de valider l'un par rapport à l'autre.
Nous avons essayé de montrer que ce discours était idéologique: il fonctionne parce que tout le monde lui accorde crédit, mais la réalité est bien plus complexe et rétive à la modélisation. Il est illusoire d'espérer valider un logiciel par rapport à une spécification, et il est encore plus illusoire d'espérer que ce processus mène à un résultat probant. Non pas que des succès locaux, dans certaines conditions précises, ne puissent être obtenus, mais le cas général et le plus courant est l'inaccessibilité de quelque chose comme une spécification contre quoi valider un logiciel.
L'objectif est maintenant de tracer des pistes: que faire ici et maintenant ? Une première simple est: rien. Cette réponse se satisfait du consensus existant, trouve ses aises dans l'acceptation de la réalité spectaculaire contemporaine dans laquelle le vrai est un moment du faux, accepte l'existence d'un discours de domination techno-rationaliste pour lequel la question primordiale est: à quoi ça sert ?
Pour ceux qui ne s'en satisferont pas, il existe des alternatives, des voies - et des voix - de traverses, qui sans haine ni violence, en douceur, de l'intérieur, fracturent la carapace isolante qui nous coupe du monde. Il nous appartient d'explorer ces voies.
Tous les modèles sont faux, certains sont utiles.
Dans La Condition Post-moderne, (Minuit, 1980), J.-F. Lyotard analyse les deux discours de légitimation, deux nouveaux jeux de langage, qui se sont substitué aux anciens "grands récits", ceux qui autrefois, c'est-à-dire avant le 20° siècle, ont cherché à remplacer un autre grand récit, la religion par, au choix: la marche de l'Esprit dans l'Histoire, le progrès de` l'Humanité.
Le premier discours est, pour faire court, celui du système capitaliste et des états modernes qui lui sont subordonnés. Ce discours est basé sur la maximisation de la performance et l'atteinte d'objectifs, la seule modalité acceptable est celle de la performativité. Le seul critère de jugement devient alors l'efficacité et, dans sa version extrême, ce discours est celui des régimes totalitaires plus ou moins barbares qui ont jalonné le siècle. Mais c'est aussi celui des démocraties qui, au travers de la valorisation du consensus, de la banalisation de modèles de performances individuelles, parviennent à donner à ce discours la force de l'évidence.
Ce discours s'appuie sur une vision naïvement systémique et mécaniste du monde, du monde social en particulier, sur un substrat de langage scientifique hérité du positivisme qui n'est plus celui de la science en train de se faire. La question centrale devient: à quoi ça sert ? et non plus: est-ce juste ? ou même: est-ce vrai ?
Le discours scientifique s'est autrefois légitimé par la prouvabilité ou la réfutabilité, c'est-à-dire l'exigence 1) que tout énoncé puisse être prouvé, et 2) que cette preuve soit reproductible. Ce mode de légitimation suppose la formation d'émetteurs et de récepteurs d'énoncés scientifique, les derniers ayant vocation à rejoindre les premiers. Cette formation suppose à son tour une société capable de soutenir et encourager à son tour cet effort de formation, donc d'accroissement du discours scientifique.
Pour légitimer cette société, le discours scientifique sort de la catégorie des énoncés dénotatifs - les énoncés sur les choses du monde - pour entrer dans la catégorie des énoncés prescriptifs - ce qu'il est bon/juste/vrai faire - et performatifs les ordres, les plans et les actions. Il propose un récit normatif le positivisme, le progrès scientifique, la marche de l'humanité, les lumières de la civilisation - qui légitime un discours dans l'ordre du politique et du social - en gros, la suprématie occidentale, le colonialisme, l'impérialisme, la société bourgeoise. La société le lui rend bien qui valorise et légitime à son tour le discours scientifique, en particulier par le recyclage d'une vieille modalité du discours: le récit épique des héros de la science et de la raison (Galilée, Newton, Voltaire, Pasteur, Edison, Einstein...).
Quand le discours scientifique perd sa capacité à produire un récit normatif - plus personne ne croît sérieusement que la science apporte un progrès continu - et épique - il n'est que de voir la désaffection pour les études scientifiques et l'image déclassée du chercheur, il ne peut plus légitimer la société qui l'abrite. Celle-ci va donc chercher ailleurs, en elle-même, sa source de légitimité, en l'occurence dans la fuite en avant du discours performatif et la subordination de tous les énoncés au seul critére de leur performativité. Et en retour, elle va exiger de la science qui ne lui fournit plus de sens qu'elle s'aligne sur ce discours. C'est l'avénement de la technoscience, le triomphe de l'ingénieur et surtout du décideur qui incarne le plus pur véhicule de la performativité puisqu'il n'a pour seule et unique fonction que de décider donc de faire faire
On remarque que malgré tout, le décideur ne peut se passer d'autres modes de discours pour parfaire sa légitimation. Il investit le discours épique en devenant une figure de héros - non seulement au travers du personnage de l'entrepreneur - Gates, Ellison, Branson... ce qui n'est pas neuf puisque cette figure faisait déjà partie de la vulgate libérale des XIX et XX siècles, mais surtout au travers de celui du patron - Seillières, Parisot en France, Puech en Allemagne - et aussi du trader. Mais comme pour tout grand récit, cette légitimation tourne un peu court: à l'ère post-moderne, les héros ne sont plus unidimensionnels et voici Jérôme Kerviel en héros maudit.
La figure du décideur investit aussi le discours normatif et prescriptif - celui qui décide du Bon et du Vrai, de ce qu'il faut et ne faut pas faire ainsi bien sûr que le discours déontique - de ce qui est Juste. Est Bon, Vrai ou Juste ce qui contribue positivement à la performance, et il devient donc facile de classer, normer et évaluer les comportements et les discours sur cette échelle unique. A contrario, bien sûr, est Mal, Faux et Injuste ce qui contribue négativement à la performance. Comme avec le discours scientifique ancienne manière, une boucle de légitimation positive entre les catégories de discours subordonnées et la catégorie principale du discours performatif permet à chacune de trouver en l'autre une source externe de légitimité.
L'obsession performative est à son summum dans l'obsession de la mesure: mesures d'audiences, mesures de qualité infiniment variées, mesures de rentabilité, débit, productivité, planification du découpage du temps et de l'espace; dans celle de l'objectif, du but et de la motivation; aussi bien que dans le crédit démesuré apporté au concept de valeur qui est utilisé en proportion inverse de la précision de son contenu sémantique. Mesure, objectif, valeur construisent l'espace strié dans lequel chaque chose, être ou discours doit avoir ses coordonnées.
Dans le temps où le système se reconstruisait une légitimité par dessus le discours scientifique, celui-ci, tout du moins sa fraction la plus avancée et la moins soumise aux intérêts technocentrés mathématiques pures, physique théorique, sciences humaines abandonnait toute ambition de produire, maintenant et pour les siècles à venir, un discours dénotatif unique et univoque qui soit totalement et intégralement, si ce n'est dans les faits du moins dans ses principes, réfutable ou prouvable. A la place s'est constitué une nouvelle modalité du discours scientifique - à moins qu'elle n'ait toujours été là et ne se découvrît que tardivement - basée sur la fécondité et qui accepte comme fondation sémantique le langage naturel, avec toute son ambiguïté, ses idiotismes, ses zones d'ombres et ses floues.
La pouvrabilité ou la réfutabilité d'une idée n'est plus aussi primordiale. Elle reste une condition de base du discours scientifique, une sorte de substrat commun accepté par tous comme un horizon indépassable, mais cède le pas à ce nouveau critère: quels nouveaux jeux de langages me permet de produire une idée ? quels nouveaux coups avec les anciennes règles ? ou quelles nouvelles règles ?
L'informatique - la télématique comme l'appelle Lyotard - peut s'incarner dans les deux aspects:
Concept qui est attribué collectivement à un ensemble de penseurs/philosophes contemporains: Derrida, Foucault, Lacan, Deleuze (avec et sans Guattari), Virilio, Latour (sociologue et épistémologue, critique du scientisme et du positivisme, met à jour les processus sociaux dans la production des découvertes scientifiques), Eco (linguiste et romancier, auteur notamment d'une joli image de la condition amoureuse à l'ère du post-modernisme), Kristeva (linguiste), Maurice G. Dantec (romancier, prétendument post-moderne mais ouvertement fachisant).
Le post-modernisme est la condition de l'être humain désenchanté, sans normes et lois transcendantes, dans un monde en apparence chaotique, bombardé d'informations contradictoires. Le modernisme est l'ére du progrés, de la marche en avant de l'humanité vers un avenir radieux, des lendemains qui chantent, des systèmes, et aussi bien sûr du totalitarisme. Le totalitarisme est en germe dans toutes les pensées systématiques. A contrario, les post-modernes déploient une pensée de la marge et sur la marge, une position critique, y compris de la critique elle-même, une déconstruction (terme issu de Derrida) systématique de tous les schémas de pensée.
Le post-modernisme est le règne de l'ironie: nous ne sommes plus dupe. La tâche du philosophe (d'après Qu'est-ce que la philosophie ?Deleuze et Guattari, Ed. Minuit) est de créer des concepts en tracant un plan d'immanence ou coupe dans la masse du chaos infiniment en mouvement et protéiforme (je ne comprends pas tout mais l'image est saisissante). Il n'y a pas de vérité, ou plutôt la vérité est subordonnée à certaines relations entre concepts, à certains agencements. Il y a plutôt des degrés d'importance (relevance). Ceci peut mener aisément au relativisme, c'est-à-dire à l'indifférenciation entre toutes les valeurs, toutes les positions, toutes les croyances, toutes les pensées. Cette indifférence est toutefois caractéristique de la non-pensée.
Le post-modernisme oppose la dynamique contre la statique, le nomade contre le sédentaire, l'espace lisse à l'espace strié (ie. ordonné), la carte au modèle, avec une nette préférence (?) pour les premiers (voir Mille plateauxDeleuze et Guattari, Ed. Minuit). L'ennemi est ici l'état en tant que pouvoir centralisateur, imperium normatif, érecteur de murs, qui s'oppose aussi bien au réseau de cités qu'à la horde nomade. L'ironie est que la posture obligatoirement défensive de l'état contre tout ce qui menace son ordonnancement l'oblige à instaurer une machine de guerre dont l'essence est la destruction de l'état.
Aprés le Cogito ergo sum de Descartes, le post-modernisme dit Je deviens donc je suis. Le devenir est un concept récurrent dans les textes de Deleuze et Guattari, sous la forme d'un substantif: le devenir-femme de quequ'un. Le devenir renvoie ou est le contenu du désir. Pour le dire autrement, on passe d'une vision centrée sur les états (du moi, du monde, ...) à une vision centrée sur les transitions: les états ne sont que des instants fugaces, on devient toujours autre à moins d'être mort.
Face au chaos et la menace de l'indifférence, l'homme et la femme post-moderne sont seuls. Dieu est mort depuis longtemps et tout ce qui pouvait le remplacer ne va pas fort (tous les -ismes divers et variés ayant occupés la scène de la première moitié du XXème siècle). Toute pensée pré-conçue est vouée à l'échec face à la multitudes d'expériences qui vit et qui constitue chacun de nous: le cliché lui aussi est mort et ne permet plus de trier.
La tentation est grande, d'autant plus qu'elle est constitutive de la nouvelle pensée dominante, de se couler dans le flux indifférencié, de devenir soi-même fluide, mouvant, nomade, ouvert à tous vents, au prix de l'abandon de toute pensée. Dans L'art du moteur, Ed.Galilée, Virilio fait la critique de l'accélération constante subie par nous dont le but ultime est l'étourdissement, l'abandon de tout repère fixe, l'abdication de toute résistance.
La seule stratégie viable pour préserver un nouvel humanisme, pour permettre toute pensée, n'est pas dans le retour à l'ordre ancien, impossible, mais le développement de résistances, le tracé de nouveaux plans de coupe dans le chaos, l'émergence de réseaux-machines de guerre anti-étatiques, la création de nouvelles multitudes. Le rhizome est la forme privilégiée d'organisation des groupes humains: un processus réticulé, au développement apparemment chaotique et incontrôlé, susceptible de s'enterrer en ressurgir plus loin ou plus tard.
Cette pensée semble aujourd'hui se cristalliser en une nébuleuse alter-éco-mondialiste qui par un curieux effet se mue progressivement en nouvelle pensée dominante à mesure qu'elle se diffuse, se démocratise et se normalise.
Le post-modernisme se caractérise aussi par la récupération des concepts, le recyclage, les accouplements contre-nature ou les confrontations explosives, la disparition des frontières stables entre haute et basse culture, la revendication minoritaire et la critique de la société blanche capitaliste à partir de ses marges: noirs, arabes, femmes, homosexuels, prisonniers, fous...
La pensée pop fait-elle partie du post-modernisme ?
Dans Impostures intellectuellesSokal et Bricmont, LdP, la captation par les penseurs post-modernes de concepts et termes empruntés au sciences dures - mathématiques, physique, mécanique quantique - est stigmatisée. Les auteurs démontent et démontrent avec brio et drôlerie les contresens, faux-sens, déformations et viols caractérisés que nombre d'auteurs font subir aux concepts scientifiques qu'ils manipulent. La relativité, le théorème de Gödel, la mécanique quantique, les fractales, la topologie sont constamment utilisées par Deleuze, Lacan, Virilio et consorts en renfort de leur pensée.
Le problème est que nombre d'entre eux visent non pas un usage métaphorique de ces concepts, susceptible de porter un nouveau regard sur le champ déjè bien labouré de la philosophie, mais prétendent à un usage littéral, voire même à un enrichissement par la philosophie des concepts scientifiques. Ces prétentions sont clairement mises à bas par l'absence totale de pensée et de méthode scientifique.
Les auteurs post-modernes sont souvent difficiles à lire, la palme de l'obscurité et de l'abscons revenant parmi ceux que j'ai fréquentés à Derrida. Vocabulaire complexe et souvent para-scientifique, détournememnts, syntaxe malmenée, extrême longueur des phrases, boucles et répétitions, complexité des raisonnements, sont fréquents.
On peut aussi essayer, au-delà de la compréhension claire et parfaite d'une pensée ouvertement en mouvement et complexe, tenter de saisir l'âme de cette pensée, être sensible à la force poétique, polémique, politique de ces textes (en particulier Mille plateaux). Ne pas vouloir tout comprendre, chaque mot, chaque phrase, mais progressivement s'approprier les relations qui se font jour entre les concepts pour les éclairer: la compréhension naît de la confrontation, de la multiplicité, des déplacements qui s'opèrent dans et entre les concepts.
Guy Debord est universellement connu pour être:
Debord détestait les informaticiens (cybernéticiens), les artistes, les gauchistes, le capitalisme et un certain nombre d'autres choses qui n'en font pas un personnage consensuel. Il prônait au travers de ses écrits et de ses oeuvres (collages, cinéma) une subversion généralisée de l'art par la vie et de la vie par l'art. Il a écrit notamment le slogan "Ne travaillez jamais" sur un mur de Paris en 1956 (1953?).
Debord n'est certainement pas un auteur post-moderne, non plus d'ailleurs qu'un penseur moderne. Cela dit, sa pratique systématique du détournement de citations, sa critique radicale de la société dans tous ses aspects, son goût pour la subversion, le secret (ou plutôt la discrétion), les marges en font un membre à part entière du post-modernisme. Serait-il plutôt post-post-moderne ?
Dans sa relation au post-modernisme, l'informatique traverse trois âges:
Références: