Post commitum animal triste : Software craftsmanship, agilité

Quelques remarques sur le mouvement agile et le "software craftsmanship", suite à mon commentaire sur le blog de Christian Fauré.

Dans son billet, Christian écrit que le mouvement agile est le fruit d'une volonté de "[l]ibération de l’emprise des systèmes sociaux sur le développement du système technique.". Il conclut par:

En oeuvrant pour une plus grande qualité logicielle on oeuvre en même temps pour de meilleures conditions de travail (et, pour être plus précis, pour que le travail ne devienne pas un simple emploi): la défense du logiciel, et d’une certaine idée de celui-ci, passe par une défense des développeurs qui ne veulent pas être prolétarisés.

Je partage tout à fait cet avis. Cependant, je pense que le mouvement agile et celui du "software craftsmanship" sont loin de pousser assez loin vers la libération, ou du moins la remise en question du système social fixant actuellement les conditions de production des logiciels, et donc les conditions de travail.

Sur le manifeste pour le développement agile

Les quatre affirmations de base du manifeste pour le développement agile sont pour le moins brèves et on peut leur faire dire un peu ce que l'on veut. Par exemple on peut y voir une absurde contradiction à opposer "Les individus et leurs interactions" et "les processus et les outils" comme s'il fallait comparer leurs importances respectives, l'un allant au détriment de l'autre. Heureusement, des "principes sous-jacents" sont également donnés.

Or, je vois nombre de prescriptions dans ces principes: "en livrant rapidement et régulièrement", "satisfaire le client", "avantage compétitif au client", "Livrez fréquemment", "une préférence pour les plus courts", "quotidiennement", "plus efficace". Ces prescriptions concernent le rythme de développement ainsi que l'efficacité. Il s'agit notamment de compétitivité.

Il en ressort que l'agilité est donc une manière d'être efficace dans la course économique. Souscrire au manifeste agile revient donc à s'assujettir à cette course. Pas vraiment une libération, donc.

Ce manifeste est d'ailleurs assez affligeant en ce qu'il mélange agilité et vitesse. L'agilité, dans son aspect dynamique, ne nécessite pas forcément d'aller le plus vite possible. Mais l'agilité définie en creu dans le manifeste semble surtout consister à gérer des contraintes temporelles et de compétition.

Sur le "software craftsmanship"

Comme son nom l'indique, le mouvement du "software craftsmanship" revendique l'aspect artisanal du développement logiciel et a lui aussi son manifeste.

On trouve dans ce manifeste des principes de base tout aussi brefs que dans le manifeste pour le développement agile:

"Pas seulement des logiciels opérationnels, mais aussi des logiciels bien conçus". Sans doute le principe qui a le plus de rapport avec l'artisanat dans la recherche de qualité, voire de beauté, qu'on associe à cette figure.
"Pas seulement les individus et leurs interactions, mais aussi une communauté de professionnels". Il est donc question de vendre des savoir-faire.
"Pas seulement l'adaptation aux changements, mais aussi l'ajout constant de la valeur". Mais de la valeur pour qui ? pour son auteur, pour la société dans son ensemble ou bien plutôt pour le client ?
"Pas seulement la collaboration avec les clients, mais aussi des partenariats productifs". Ca ne mange pas de pain.

Oui, on sent dans ce mouvement une volonté de remettre le logiciel, comme objet technique, au coeur du métier de développeur. Mais la seule vision artisanale de ce métier empêche toute remise en cause supplémentaire du système social, celui-là même qui tend actuellement à empêcher la qualité (quoi que l'on entende par là).

Associer le développeur à la seule figure de l'artisan revient à le ramener au statut antique de ce dernier: il est assujetti au client. L'artisan n'est là que pour satisfaire un client:

Dans la sphère de son métier, les capacités de l'artisan sont rigoureusement soumises à son ouvrage, son ouvrage rigoureusement soumis au besoin de l'usager. L'atisan et son art existent "en vue" du produit, le produit "en vue" du besoin. Il ne peut en être autrement tant que le produit du travail est considéré, comme c'est le cas du monde antique, eclusivement sous son aspect de valeur d'usage, non de valeur d'échange. En tant que valeur d'usage le produit se définit en effet par les services qu'il rend à celui qui s'en sert. C'est seulement en tant que valeur d'échange qu'il peut etre envisagé indépendamment de son utilisé concrète, par rapport au travail mis en lui. Dans la perspective de la valeur d'usage, le produit n'est pas vu en fonction du travail humain qui l'a créé, comme travail cristallisé ; c'est au contraire le travail qui est en fonction du produit, comme propre à satisfaire tel besoin de l'usager. Par l'intermédiaire du produit, le travail institue donc entre l'artisan et l'usager un rapport économique de servitude, une relation irréversible de moyen à fin.

[8], p. 297-298

Peu de remise en cause

Dans la société actuelle, en perpétuelle guerre économique, le client désire bien souvent être compétitif, ce qui implique de la vitesse. Si les "méthodes agiles"¹ ont un tel succès, c'est par la promesse de vitesse et de compétitivité qui leur est associée.

Se réclamer artisan et souscrire au manifeste pour un développement agile est alors paradoxal. L'artisan applique son savoir-faire, fait évoluer ses pratiques et ses outils notamment par une réflexion sur son métier, son activité. Utiliser un outil le prive d'une partie de son savoir-faire. Il doit donc toujours penser aux savoir-faire qu'il souhaite conserver, pour pouvoir les faire évoluer, et ceux qu'il accepte de déléguer à des outils, au risque d'en être dépendant².

Or, le rythme prescrit par le manifeste pour un développement agile encourage à gagner du temps, donc l'automatisation par laquelle le développeur perd des savoir-faire, sans forcément avoir le temps de choisir ceux qu'il veut garder ou non.

La libération du système social pour se consacrer au logiciel en tant qu'objet technique, ou plutôt la soustraction du logiciel aux contraintes sociales, demande donc davantage qu'une revendication d'un aspect artisanal du développement logiciel³ et d'une nécessité d'adaptation perpétuelle, tant que ces deux aspects restent dans l'optique d'une compétition, d'une soumission à la course.

La promotion d'un "mode d’existence propre des systèmes techniques" passe à mon avis par la promotion d'une figure additionnelle, celle de l'amateur.

Mise à jour (2013-11-25): David Larlet a publié une réaction.

¹ On ne dira jamais assez que le terme de "méthodes agiles" est stupide: c'est le développeur qui doit faire preuve d'agilité en adoptant des méthodes adaptées. Dire que ce sont les méthodes qui sont agiles ramène le développeur à un simple exécutant de méthodes pré-définies.

² Ce n'est pas seulement le cas de l'artisan, mais de tout individu.

³ Même si je souscrit à cet aspect, cf. ce billet.