L’informaticien, artisan des temps modernes ?

Je viens de lire à l’instant un billet sur l’informatique et un parrallèle avec l’artisanat. C’est un sujet qui revient souvent. Mais peut-on comparer notre métier avec la pratique de l’artisanat ?

Personnellement je ne le pense pas, notre métier peut couvrir un large spectre, du technicien spécialisé à l’expert dans son domaine mais en aucun cas je ne le comparerai à de l’artisanat.

Allez, je vais tenter un petit billet sur le sujet.

En fait je compare l’évolution des pratiques de création logicielles à celle de l’automobile du début du siècle (le 20ème évidemment ^^).
En prenant les grandes phases de l’industrie automobile on retrouve (très) schématiquement les suivantes :

Le système actuel est encore un mix entre fordisme et toyotisme.

Pour les logiciels informatique on retrouve une évolution quasi similaire :

  • l’ordinateur personnel voit l’arrivée d’OS créé par des amateurs (Steve Wozniak, Bill Gates, Paul Allen). De cette période c’est bien souvent des petits logiciels très simples et conçu par des amateurs toujours qui marqueront l’histoire (pong par exemple).
  • transposition des méthodes industrielles et/ou venant du batiment dans l’informatique avec l’arrivée d’un vocabulaire nouveau : architecture, cycle en cascade (équivalent du fordisme), MOA/MOE pour la France.
  • arrivée du développement lean (transposition du toyotisme dans l’informatique) et des méthodes agiles qui, comme pour le toyotisme, « se base à nouveau sur les compétences et la qualification des ressources humaines »

En suivant cette petite comparaison rapide, vous comprendrez que je n’adhère pas à cette vision de « l’artisan informatique ». Tout simplement parce que le processus de développement informatique s’inscrit depuis longtemps maintenant dans un contexte qui dépasse le simple fait de réaliser le logiciel : la vente, la production, la distribution, la maintenance sont désormais des phases à part entières et qui ne sont pas dans les mains des mêmes équipes (ou tout du moins très rarement).

Le Fordisme dans l’informatique

Peut-on cependant comparer le fordisme avec ce qui se fait actuellement dans le développement logiciel ?
Oui dans les grandes lignes, on retrouve :

  • la division du travail entre conception et réalisation ainsi que la parcellisation des tâches et la chaine de montage (conception, réalisation, tests, assemblage etc…)
  • la standardisation (les standards informatiques, les protocoles de communication etc…)

De plus dans le fordisme on a deux choses :

  • la parcellisation du travail qui entraine une spécialisation des individus et qui nécessite des profils moins élévé (et donc moins chers)
  • l’évolution du pouvoir d’achat, car le fordisme insiste sur le fait de motiver par une meilleure paye les salariés afin de lutter contre le turnover

En informatique la parcellisation des tâches a entrainé une spécialisation par activité : le test, le développement dans un langage spécifique etc… Les profils peuvent être moins qualifiés. A l’extrême on peut même voir de l’offshore focalisé sur un type de tâche très spécifique : création de pages web, test sur outil spécifique etc…
Quand au pouvoir d’achat, si les profils qualifiés sont désormais mis de côté parce que plus nécessaire, les profils moins qualifiés sont eux par contre payés au dessus des standards. Le parallèle est simple avec l’offshore où on cherche des profils moins qualifiés à l’étranger que l’on paiera correctement selon les standards locaux. (1)

Alors oui, on pourra argumenter que les chaines de montage informatique sont bien moins caricaturale que celles aperçu dans « Les temps modernes » de Chaplin. Effectivement, mais il ne faut pas minimiser l’industrialisation croissante des méthodes de production (MDA, ORM etc…), l’amélioration constante des outils et la spécialisation toujours plus extrême demandé à ceux qui réalisent.

Cette approche « rationnelle » de la chaine de production logicielle est cependant mise en défaut :

  • il est très difficile de décorreller la conception et la réalisation (2)
  • la division du travail dans sa forme cascade ne permet pas d’avoir une vue d’ensemble sur le processus

C’est d’ailleurs l’analyse du faible taux de succès de cette approche qui a mené vers les méthodes agiles.

Le toyotisme en informatique

Le parallèle est bien plus simple puisque le développement Lean est la transposition pure et simple du toyotisme dans la gestion de logicielle. Et l’agile partage plusieurs valeurs en communs avec le Lean.

On retrouve parmi les principes qui motivent ces deux mouvements :

Ces principes sous-tendent donc que l’on se base à nouveau sur les compétences individuelles et on met en avant le principe d’autonomisation. On redonne les moyens aux équipes d’être autonomes.

 

Mais ce n’est toujours pas de l’artisanat !

Cependant, même dans un projet en mode Lean/agile je ne partage pas l’avis d’un développement artisanal pour les raisons suivantes

1) Artisanal présuppose un travail manuel sans aide automatisée

Artisanal dans l’esprit de certain c’est l’excuse pour ne pas utiliser d’outils pour les tests, la qualimétrie, voire pour ne pas faire tests du tout.
En fait pour ces personnes l’utilisation même du mot « usine logicielle » les choque. On est un artisan talentueux et on travaille sans filet ici monsieur !

La réflexion type :

« ça fait x années que je compile moi-même mes packages et que je fais mes zips à la main pour livrer, je ne vois pas le souci. »

2) Artisanal présuppose un travail personnel sur lequel on gardera la paternité ad vitam eternam

Pour d’autres encore, la vision artisanale c’est une vision proche du compagnonnage. C’est le maitre d’art qui cajole son bébé pendant des années avec éventuellement des compagnons pour l’aider mais c’est le maitre qui régule tout. Sa méthode est originale, unique et sera reconnu comme tel plus tard par la postérité (3).

Ce comportement conduit à deux choses :

  • l’enfermement vis à vis des solutions prônées par d’autres et le fait de privilégier uniquement le travail de son propre atelier. Exit donc les patrons de conception, l’open source etc…

La réflexion type :

« écoutes, les design patterns, le découplage des couches etc… c’est surement bien beau dans les livres mais tu sais ici on a besoin de perf et on sait ce qu’on fait de toute façon. »

  • des solutions non maintenables par les autres. On accumule la dette technique et on oublie deux points fondamentaux « 80% du temps de vie d’une application est passé en maintenance » et « Rarement une application est maintenue toute sa vie par son auteur »

La réflexion type :

« Oui mon fichier fait 10000 lignes mais il super génial, ça fait 4 ans que je suis dessus, je sais exactement ce qui est fait où et quand. Bon c’est un peu complexe mais c’est super perf ! »

Bon et puis tout simplement, l’art présuppose une création qui s’adresse aux sens, aux émotions et à l’intellect. Faire un mapping objet relationnel n’éveille pas d’émotions en moi, même s’il est bien fait ^^ En fait, je n’imagine pas encore dans un musée voir le listing d’un programme Cobol, C ou Java 😉 (4)

 


(1) Encore que la logique actuelle tend à déléguer la gestion des ressources humaines localement et donc à tirer sur les prix ce qui créé un turnover important…
(2) On y a longtemps cru avec MDA http://fr.wikipedia.org/wiki/Model_driven_architecture mais au final, la formalisation UML n’a pas tant percé que cela.
(3) Évidemment je caricature, dans l’artisanat aussi on respecte un état de l’art
(4) Par contre j’avoue que certaines créations d’interface utilisateurs peuvent éventuellement se ranger dans cette catégorie. Il y a quelques ergonomes/designers que je pourrais éventuellement ranger dans la catégorie artistes.

4 réflexions sur “L’informaticien, artisan des temps modernes ?

  1. je trouve cette vision un peu fermée…

    n’oublions pas que la plupart des vraies innovations viennent d’isolés, assimilables à des artisans, qui maîtrisent leurs techniques et peaufinent leurs bijoux de manière originale, pas d’usines qui suivent les procédures à la lettre…

    le codeur est un ouvrier, l’analyste est un artisan.

    et… dire que concevoir à l’artisanal confine à la fermeture est très erroné, comme vision… autant une chaise ikéa cassée n’aura pas beaucoup de chance de pouvoir être réparée, autant une chaise sur mesure, en chêne massif, créée dans les règles de l’art, pourra être sauvée par n’importe quel ébéniste qui maîtrise son domaine…

    en fait, tu confonds artisan (qui est un grand professionnel, expérimenté) et amateur (même avancé), en faisant cette analyse… il ne faut pas confondre amateur et artisan, tout comme il ne faut pas confondre codeur et analyste développeur…

    de bons codeurs, il y en a à la pelle… des bons petits soldats du claviers, qui peuvent développer des fonctions et des classes à la chaîne, avec une indentation et des commentaires suivant parfaitement le guideline de sa compagnie… par contre, les bons analystes, qui sauront trouver les idées originales et les solutions à mettre en oeuvre pour faire face à chaque problème sont très rares.

    Un grand professionnel de l’informatique, qui sait comment ça se passe dans le milieux, sortira toujours un code mijoté aux petits oignons, ou les performances seront au rendez vous, et qui sera maintenable au possible. Tout comme un bon codeur, mais avec l’expérience et les idées en plus…

    Tu sais, c’est pour ça que même dans les grandes usines de développement (toutes catégories confondues) on fait encore appel aux artisans pour trouver des solutions originales… il ne faut pas croire que les voitures innovantes sortent de la tête de concepteurs formatés à la procédure.

  2. je trouve cette vision un peu fermée…

    n’oublions pas que la plupart des vraies innovations viennent d’isolés, assimilables à des artisans, qui maîtrisent leurs techniques et peaufinent leurs bijoux de manière originale, pas d’usines qui suivent les procédures à la lettre…

    le codeur est un ouvrier, l’analyste est un artisan.

    et… dire que concevoir à l’artisanal confine à la fermeture est très erroné, comme vision… autant une chaise ikéa cassée n’aura pas beaucoup de chance de pouvoir être réparée, autant une chaise sur mesure, en chêne massif, créée dans les règles de l’art, pourra être sauvée par n’importe quel ébéniste qui maîtrise son domaine…

    en fait, tu confonds artisan (qui est un grand professionnel, expérimenté) et amateur (même avancé), en faisant cette analyse… il ne faut pas confondre amateur et artisan, tout comme il ne faut pas confondre codeur et analyste développeur…

    de bons codeurs, il y en a à la pelle… des bons petits soldats du claviers, qui peuvent développer des fonctions et des classes à la chaîne, avec une indentation et des commentaires suivant parfaitement le guideline de sa compagnie… par contre, les bons analystes, qui sauront trouver les idées originales et les solutions à mettre en oeuvre pour faire face à chaque problème sont très rares.

    Un grand professionnel de l’informatique, qui sait comment ça se passe dans le milieux, sortira toujours un code mijoté aux petits oignons, ou les performances seront au rendez vous, et qui sera maintenable au possible. Tout comme un bon codeur, mais avec l’expérience et les idées en plus…

    Tu sais, c’est pour ça que même dans les grandes usines de développement (toutes catégories confondues) on fait encore appel aux artisans pour trouver des solutions originales… il ne faut pas croire que les voitures innovantes sortent de la tête de concepteurs formatés à la procédure.

  3. > dire que concevoir à l’artisanal confine à la fermeture est très erroné, comme vision

    Oui, c’est pour ca que j’avais mis un petit renvoi dans le texte :

    (3) Évidemment je caricature, dans l’artisanat aussi on respecte un état de l’art

    Et c’est justement cet état de l’art (http://fr.wikipedia.org/wiki/%C3%89tat_de_l%27art) que doit respecter tout expert dans son domaine.

    Pour le reste ce n’est pas contradictoire avec ce que je décris, effectivement il y a de très bons experts. Je réfute la vision de l’artisanat cependant car notre contexte est quasi toujours industriel, l’état de l’art ne fait que refléter les standards de développements issus de l’entreprise. Après tout dépend de sa définition de l’artisan.

    Ma définition est par exemple différente de ce qui est décrit dans le manifeste sur le software craftmanship : http://manifesto.softwarecraftsmanship.org/
    Je ne vois pas en quoi : faire bien son boulot, participer a des communautés, apporter de la valeur ajoutée et faire un bon travail en collaboration répond à une définition de l’artisan.
    Pour autant il faut peut être simplement le voir comme une nouvelle définition : « l’artisan logiciel » et non plus simplement « l’artisan ».

  4. > dire que concevoir à l’artisanal confine à la fermeture est très erroné, comme vision

    Oui, c’est pour ca que j’avais mis un petit renvoi dans le texte :

    (3) Évidemment je caricature, dans l’artisanat aussi on respecte un état de l’art

    Et c’est justement cet état de l’art (http://fr.wikipedia.org/wiki/%C3%89tat_de_l%27art) que doit respecter tout expert dans son domaine.

    Pour le reste ce n’est pas contradictoire avec ce que je décris, effectivement il y a de très bons experts. Je réfute la vision de l’artisanat cependant car notre contexte est quasi toujours industriel, l’état de l’art ne fait que refléter les standards de développements issus de l’entreprise. Après tout dépend de sa définition de l’artisan.

    Ma définition est par exemple différente de ce qui est décrit dans le manifeste sur le software craftmanship : http://manifesto.softwarecraftsmanship.org/
    Je ne vois pas en quoi : faire bien son boulot, participer a des communautés, apporter de la valeur ajoutée et faire un bon travail en collaboration répond à une définition de l’artisan.
    Pour autant il faut peut être simplement le voir comme une nouvelle définition : « l’artisan logiciel » et non plus simplement « l’artisan ».

Laisser un commentaire