Software Craftsmanship & Mode d’existence des objets techniques

swcraftmanship

Les systèmes techniques doivent en permanence être corrélés avec les systèmes sociaux. Par système social il faut entendre tout ce qui relève des organisations collectives : un système politique, un système de soin, d’éducation, une organisation du droit, du commerce, du travail, etc.

L’articulation entre les systèmes sociaux et les systèmes techniques est celle qu’a mis en évidence Bertrand Gille en expliquant que la dynamique d’évolution des systèmes techniques était à l’origine d’un désajustement entre système technique et système social. Ce qui conduit inévitablement a des périodes de troubles et de crises.

Comme les évolutions technologiques sont devenues chroniques et quotidienne, nous sommes dans un désajustement systémique.

Mais il ne faudrait pas croire pour autant que les systèmes sociaux ne sont que des systèmes passifs qui se contentent de réagir face à l’évolution du système technique.

Si l’on regarde les projets informatiques en tant qu’ils sont la mise en oeuvre (on parle d’implémentation) d’un système technique au sein de systèmes sociaux on peut constater ce désajustement, en voici quelques exemples :

  • le découpage en mode projet (build) et maintenance (run) est un découpage qui ne correspond pas au système technique lui-même : il est par exemple surdéterminé par les logiques comptables (amortissement, immobilisation, ou encore Opex versus Capex).
  • Les systèmes juridiques perturbent également le développement des produits (« on ne peut pas faire çà car c’est illégal » est une expression qui devient récurrente dès que l’on touche aux données )
  • Autre aspect significatif : la confusion régulière entre le projet et le produit (surtout dans les SSII où l’on ne connaît que les projets, jamais vraiment les produits) : ainsi les méthodes de projets peuvent aller à l’encontre du produit technique. C’est typiquement le sens des démarches Agiles que de travailler différemment pour ne pas que le mode projet tue le système technique (le produit) dans l’oeuf.

 Dans chacun des cas ci-dessus, le système technique n’est pas un rouleau compresseur qui suit son bonhomme de chemin en toute indépendance et auxquels les systèmes sociaux – c’est à dire les organisations – devraient se réajuster. Ces exemples montrent que les systèmes sociaux (systèmes comptables, juridiques, commerciaux, modes projets, etc.) peuvent également jouer une partition qui va à l’encontre de ceux qui sont au plus près du mode d’existence des objets techniques : ceux qui les conçoivent fonctionnellement et techniquement.

Le mouvement Agile, notamment celui autour de l’ eXtreme Programming,  est le fruit d’une volonté de libération de ceux qui conçoivent et développent les logiciels. Mais libération de quoi ? Libération de l’emprise des systèmes sociaux sur le développement du système technique. En ce sens, c’est un mouvement qui promeut l’idée d’un mode d’existence propre des systèmes techniques. Car prendre à rebours les logiques propres du système technique, notamment à cause de l’influence de certains système sociaux, c’est d’une part la promesse d’un logiciel qui ne peut pas fonctionner, et d’autre part c’est la garantie pour les développeurs de travailler dans de très mauvaises conditions.

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 (cf. La prolétarisation dans les sociétés informatiques). “Software Craftsmanship” et mode d’existence propre des systèmes techniques vont de pair.

Bonjour Christian,

Dans le software craftmanship et les méthodes agiles, il y a tout de même un sacré asservissement au rythme du marché (cf. le manifeste agile ses toutes ses prescriptions de rythme), donc pas tant que ça une libération du système social.

[Reply]

Excellente mise en avant de l’intérêt du Software Craftmanship!
Je n’avais jamais lu votre article sur la prolétarisation du développeur et c’est aussi du grand article.

Merci beaucoup !
Un développeur de plus de 30 ans 😉

[Reply]

Serait-il possible de développer ?

J’ai beau relire le manifeste en question http://www.agilemanifesto.org/iso/fr/ je n’y vois pas cet asservissement.

[Reply]

Bon article, mais j’ai décroché à partir de cette phrase:
« [l’agilité] est un mouvement qui promeut l’idée d’un mode d’existence propre des systèmes techniques. »

J’ai probablement mal compris l’intention, mais par exemple l’agilité ne permet pas de s’affranchir du cadre juridique.

Les systèmes sociaux sont beaucoup plus larges, ils incluent les clients, les utilisateurs… qui ont leurs propres formes d’organisation. Je ne vois donc pas comment les systèmes techniques pourraient exister sans.

AMHA la force de l’agilité est justement de déconstruire en partie la notion de systémique, car les structures sont trop complexes pour être analysés et restreintes à un ensemble modulaire ou hierarchique.

[Reply]

@gregory Il y a une référence à Gilbert Simondon « Du mode d’existence des objets techniques ».

On ne peut jamais s’affranchir des systèmes sociaux, comme tu le soulignes, mais si je reprends en substance un exemple de Simondon, : l’ingénieur qui va concevoir une voiture aérodynamique, en étant au plus prêt du « mode d’être » de la voiture, peut voir d’un mauvais oeil qu’on lui impose de rajouter quelque chose qui n’apporte rien à l’objet technique (par exemple un aileron plus grand parce que les clients aiment çà) , et qui peut même dégrader le fonctionnement de l’objet technique.
Dans le monde logiciel tu peux avoir des demandes qui vont à rebrousse poil du mode de fonctionnent du système, et çà peut énerver un développeur de dégrader les performances de son système pour une *feature* qui, a ses yeux, est surtout cosmétique ou superflue.
Il y a un jeu de tension entre les tendances du système technique et celles du système social. Mais comme dit Marc Voinchet : si y a pas de frottement il n’y pas de plaisir 🙂

[Reply]

Cela apparaît dans les « principes sous-jacents »:
http://www.agilemanifesto.org/iso/fr/principles.html

On trouve par exemple: « 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 ».

De ce point de vue, le software craftmanship, comme son nom l’indique, replace l’activité de développement dans une vue artisanale. Et avec cette figure de l’artisan, c’est la position traditionnelle de ce dernier dans la société qui vient : l’artisan est au service du client, il en subit donc les rythmes, etc. voire aussi l’opposition entre architecte et artisan relevée par J.P. Vernant. Pas bien le temps de développer là, mais je compte le faire cette semaine.

Je suis d’accord avec le fait que la figure de l’artisan intervient dans le métier de développeur (cf. http://www.oranadoz.net/sur-le-metier-de-developpeur-de-logiciels/#artisan), mais cette revendication n’est selon moi pas suffisante pour libérer le développeur du système social en l’état actuel.

[Reply]

D’accord avec Christian, l’utilisateur saisit rarement la beauté de l’objet technique créé par le développeur, et ses demandes de fonctionnalités absurdes le prouvent souvent. Il revient alors à l’esprit le scketch de Fernand Raynaud: « Avec deux croissants » 🙂

[Reply]

[…] et passionné, il est souvent difficile de l’expliquer à des personnes non techniques. Cet article sur le Software Craftmanship nous montre que les projets informatiques sont la mise en oeuvre (on parle d’implémentation) […]

@oranadoz tu fais une mauvaise interprétation de ce qui est dit dans le manifeste, tes citations sont hors contexte et perdent tout leur sens.

On livre « rapidement et régulièrement des fonctionnalités
à grande valeur ajoutée ».
« early » a été traduit par « rapidement », le véritable sens est de livrer « tôt » c’est à dire en premier les fonctionnalités qui apportent le plus de valeur ajoutée.
On livre fréquemment pour obtenir du feedback, le but étant de s’assurer que ce que l’on fait a du sens et de s’adapter aux changements, certainement pas de bacler notre notre travail pour avoir des rentrées d’argent immédiates.
Tu fais abstraction du « rythme soutenable » qui est fondamental.
Je te conseille de lire l’historique du manifeste qui aide à mieux le comprendre et d’en discuter avec de vrais agilistes ou artisans.

Il n’y a pas d’opposition entre les artisans et les agilistes, vu que le software craftsmanship manifesto vient compléter l’agile manifesto pour éviter justement ce genre de mauvaise interprétation. Un artisan est avant tout un agiliste.

@christian mon point était justement d’arréter de faire la distinction entre système social et système technique.
Je pense que l’agilité permet enfin de faire sauter cette frontière en mobilisant les énergies vers des objectifs clairs et en se focalisant sur ce qui a vraiment de la valeur (en étant factuel).
On ne développe plus un produit, on répond aux besoins d’un groupe social.
Si le besoin est esthétique, on peut très bien mettre un aileron plus grand.
Je ne connais pas d’artisan ou un agiliste qui serait « énervé » d’avoir satisfait ses utilisateurs ou alors il s’est auto-proclamé ainsi sans comprendre ce que nous faisons vraiment.

Ça ne sert à rien de faire une F1 pour un père de famille qui va chercher ses enfants à l’école et ce n’est pas aux développeurs de décider ce qui est bien pour un père de famille.

En tant que développeur, agiliste et artisan, « un mouvement qui promeut l’idée d’un mode d’existence propre des systèmes techniques » est mon pire cauchemar et c’est ce contre quoi je me bas chaque jour, depuis plusieurs années.

[Reply]

Merci pour ces précisions Gregory.
Tu souhaites « arrêter de faire la distinction entre système social et système technique », mais ce n’est pas possible. On peut par contre arrêter de les opposer, mais pas de les distinguer : c’est d’ailleurs ce que tu fais apparemment car tu ne cherches pas à pousser les performances techniques mais à « répondre à un besoin social. »

Par ailleurs, tes remarques sont très intéressantes et je crois que chacun a sa propre sensibilité pour savoir où il met le curseur dans la composition entre système technique et système social.

[Reply]

« ce n’est pas possible » est exactement la phrase type que l’on entend face au changement et pourtant, ce n’est qu’une vue de l’esprit. 🙂

Il ne s’agit pas de MA sensibilité, si je réagis c’est que beaucoup de gens se méprennent sur ce qu’est véritablement le software craftsmanship et cet article, malgré qu’il soit très bien écrit, induit en erreur.

Dans le SC manifesto il y a une rubrique essentielle, bien plus importante que le manifeste lui même, c’est le « further reading »: http://manifesto.softwarecraftsmanship.org/#/en/reading

Parmis les liens il y a cet article par lequel à mon avis tout le monde devrait commencer: http://blog.oshineye.com/2011/01/software-craftsmanship-more-than-just.html

Et il y a celui là: http://www.davethehat.com/dh/blog/2009/05/25/software-craftsmanship-can-we-just-get-over-it/

dont voici un passage dans le paragraphe « Building a community of practice around… »:

« […] the interesting conversations (par opposition aux guildes), both for individuals and for organisations of all sizes, are about breaking down barriers — between companies and their markets, development organisations and the businesses in which they’re embedded, software developers and the users of their software. »

La suite est aussi très intéressante.

Je suis désolé si je me suis permis d’insister, mais je sens une dérive du mouvement et je n’ai pas envie que l’on se retrouve dans la même situation que l’agilité ajourd’hui ou la première vague de lean dans années 70/80, à savoir que pour attirer le chalant on a omis de dire que c’était en fait très difficile d’être agile et qu’on se retrouve maintenant avec beaucoup de n’importe quoi sous la bannière agile.

[Reply]

Je suis de bonne humeur, alors je pourrais répondre qu’en disant « je sens une dérive du mouvement « , tu es toi même réticent aux changements et gardien d’une identité d’origine non pervertie avec un penchant réactionnaire 🙂

Mais j’entends bien tes remarques et tes motivations que je crois comprendre. Merci pour les références et les liens.

C’est marrant mais Takeushi et Nonaka sont à l’origine des deux mouvements : l’agile et le knowledge management . J’ai l’impression que le SC tel qu’en parle l’article que tu cites est très imprégné de knowledge management pour le coup.

[Reply]

[je ne sais pourquoi je ne reçois pas de message quand on me cite dans un commentaire, c’est dommage]

@Grégory

Je sais bien qu’il y a plusieurs interprétations à ce qu’est l’agile. Tu dis que mon interprétation est « mauvaise », et je comprends qu’elle ne soit pas dans le sens que tu exprimes, et auquel j’adhère en partie.
Cependant, on ne peut nier que le terme d’agile a été repris, je dirais même volé, pour exprimer une promesse de rendement.
Le terme de « compétitivité », même hors contexte, est présent et ne me semble pas sujet à interprétation au point de lui faire dire autre chose que ce qu’il dit. De même que vouloir fournir en premier la feature avec la plus grande valeur ajoutée est une prescription d’organisation par rapport au marché, non ?
Alors si ce manifeste est si has been, il en faudrait peut-être un nouveau ?
Les termes d’agilités, de « méthodes agiles », sont devenues un fourre-tout. Pour moi, à partir du moment où on nomme une méthode, on commence à la figer, il en est alors fini de l’agilité, qui consiste justement à adopter des méthodes et à les adapter à son environnement, comme le fait un artisan. Je pense que nous sommes d’accord ?

[Reply]

Je vous invite à en dicuter sur le groupe SC France: https://plus.google.com/u/0/communities/115611122573484378363

[Reply]

@oranadoz non, nous ne sommes pas d’accord. L’agilité ce n’est pas appliquer une méthode et l’adapter. C’est un changement social et pas technique. ie. « On est agile, on ne fait pas de l’agile ».

Jeff Sutherland désigne Takeushi et Nonaka comme les grands père de *Scrum* parce qu’ils utilisent la métaphore de la mélée dans un de leur article mais ils ne sont pas à l’origine du mouvement agile (scrum est la face visible de l’iceberg).

L’article dont tu fais référence est celui là: http://hbr.org/1986/01/the-new-new-product-development-game/ar/1

Il est question d’organisation apprenante et ne se limite pas au savoir faire technique.
Je suis d’accord que l’apprentissage est une facette importante du SC mais l’accent est mis non pas sur le niveau technique mais plutôt sur la démarche d’apprentissage qui est continue (cf. rythme soutenable) et liée aux interactions sociales (cf. socio-constructivisme et connectivisme).

[Reply]

 

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.