Réponse à une objection sur « la prolétarisation dans les sociétés informatiques »

Didier Girard, sur Application Servers , fait une remarque intéressante à propos de ma note sur la prolétarisation dans les société informatiques :

Dans certaines branches, l’opensource est un des vecteurs de la prolétarisation, je pense en particulier au monde java. Il y a quelques années lorsque nous devions développer une application java nous devions tout faire : coder un struts, coder un spring, coder un hibernate, coder un maven… Ce n’était pas très productif pour nos clients mais par contre c’était très formateur pour nous, ingénieurs.
Maintenant ce n’est plus le cas, les projets démarrent, les « architectes » assemblent deux ou trois frameworks et le tour est joué. La conséquence est moins réjouissante, ces « architectes » ne sont plus capables de coder un framework, tout juste sont-ils capables d’en comprendre le fonctionnement. Encore quelques années et je vais m’ennuyer ferme lorsque je recevrai un candidat pour un entretien d’embauche…

J’ai côtoyé des ingénieurs dans la plupart des industries : chimie (SNPE, Isochem, Saint Gobain), mécanique et électronique (Renault, PSA, EADS). Ainsi, les plus anciens se plaignent toujours que l’évolution des techniques fait « perdre de vue » le fonctionnement général de l’objet technique. Dans l’automobile, par exemple, certains des ingénieurs qui travaillaient sur plan n’ont pas pu se faire au travail assisté par ordinateur en CAO, ils ne « voyait plus » la voiture. Le constat est souvent le même, et on pourrait le résumer avec la remarque que nous faisait un des mes professeurs de mathématique :

Avec ces calculettes vous ne savez plus calculer.  De mon temps, il faillait faire un effort pour compter. Aujourd’hui vous rentrez une fonction et çà vous fait toute l’étude, çà vous dessine même la courbe. Ces machines vous rendent idiots !

La perte de connaissances et de savoir faire est donc une composante intrinsèque de l’évolution des techniques et des technologies, y compris dans les technologies open source de l’informatique. C’était déjà perçu par Platon qui pointait du doigt les techniques d’écriture qui externalisaient la mémoire (Stiegler souligne à ce propos que le premier discours sur le prolétariat remonte à Platon).

Cela dit, et pour revenir sur le terrain de l’informatique, je pense qu’il faut appréhender tout ça à partir du modèle en couche. Ainsi, le jeune ingénieur travaille généralement au niveau d’une couche qui correspond à l’état de sédimentation et de maturité de la technologie sur laquelle il travaille. Dans l’exemple de Didier Girard, le développeur ne va pas faire de l’assembleur, pas plus qu’il ne va re-développer un framework ; il va partir de la couche la plus haute qui masque la complexité des couches inférieures. Et c’est une chose heureuse car il faudrait 10 ans à un ingénieur pour arriver au niveau d’un Didier en Java !

Mais l’ingénieur qui utilise un framework, sans être lui-même capable d’en développer un, n’est pas pour autant prolétarisé, car il doit développer de nouvelles compétences er de nouveaux savoir-faire sur des couches supérieures. Est prolétarisé celui qui n’a pas su trouver sa place dans l’évolution des techniques. Je peux donc dire qu’entre le jeune ingénieur et Didier, c’est bien Didier qui est le plus menacé par le risque de prolétarisation, d’ailleurs il le pressent lui-même en écrivant :

« encore quelques années et je vais m’ennuyer ferme… ».

je dis que Didier est le plus menacé de prolétarisation car, contrairement au jeune ingénieur, il a quelque chose à perdre – un savoir et des connaissances – en ce sens qu’il risque de ne plus pouvoir les exercer.

Si je reviens maintenant au modèle en couche, on ne peut donc pas connaître sur le bout des doigts tous les protocoles de chaque couche, mais on doit à minima connaître les interfaces en tant que lieu d’échange entre chaque couche, car c’est à partir de là que la possibilité d’un regard critique s’exerce.

Cela dit, je crois qu’aujourd’hui le débat en matière de prolétarisation (perte de connaissance et de savoir faire qui permet de s’individuer, de se réaliser) n’est plus au niveau du débat logiciel propriétaire versus logiciel libre. Il se cristallise sutout autour des données. L’enjeu est moins l’open source que l’open data, pour aller dans le sens du commentaire de David Larlet sur la même note qui parle de  » Sociétés de Service en Données Libres ».

Ce débat se jouera bien sûr autour des plate-formes web, du software as a Service et du Cloud Computing.

Bonjour

Je ne crois pas, contrairement à vous, que didier ait quelque chose à perdre. Chaque strate technologique offre un niveau d’abstraction de plus en plus haut. En cas de problème lors du déploiement (performance, etc.) ou de bug, les non initiés se trouvent perdus. C’est pourquoi beaucoup d’entreprises payent le support …

Le problème de l’open source est que bien peu de personnes mettent le nez … dans le code. Cela pose bien sur des problèmes de sécurité, mais aussi des problèmes de continuité (perennité des dévelopements et de la communauté en charge de ce framework).

Et si vous regardez les sociétés qui aujourd’hui innovent le plus, ce sont principalements celles qui se dotent de programmeurs qui savent créer des frameworks (Googgle).

Pour sortir du cadre de Java, je dirais que le plus gros danger pour moi vient du fait que les jeunes générations n’ont pas été formées à modéliser, ni à prendre le temps de réfléchir. La facilité apparente des outils et des langages actuels est trompeuse.

Récemment j’ai donné des cours en MASTER 2 et j’ai été surpris de voir qu’à peine ma question posée, les étudiants se ruaient sur google pour en trouver la réponse! Ainsi, le savoir se transmet par mimétisme par rapport à une référence absolue: le moteur de recherche (et les enseignants du secondaire ont les mêmes problèmes). Les étudiants sont même surpris lorsqu’ils découvrent qu’il n’existe pas forcément une seule solution à un problème.

Bien sur, quand tout est stratifié, on imagine un monde ou les ressources sont « infinies » (le cloud, le grid). Or la gestion de la « scalabilité » n’est pas si simple. Et les sociétés actuelles essayent de devenir le plus green possible, donc d’utiliser les ressources au mieux.

L’échec de l’outsourcing dans de nombreux pays (faire développer des ingénieurs indiens à bas cout) à démontrer que le savoir faire, la documentation et la valorisation de certains morceaux de code (ou de certaines API ou données) allaient au dela du simple codage.

L’informatique « durable » est devenu l’un des enjeux majeurs de notre société (pour plus d’info voir: http://www.sustainableitarchitecture.com/). En effet, ces strates technologiques sur lesquelles reposent les framework se dégradent avec le temps …

[Reply]

La taylorisation aboutit à la prolétarisation…
J’ai vécu ça de manière très forte dans le multimédia, par exemple avec le logiciel Flash. Au départ cet outil très puissant permettait à quelqu’un de se débrouiller en étant à la fois graphiste/animateur, créateur de contenu et programmeur. Mais au fil des versions, il est devenu impératif de choisir, ou du moins il est devenu impossible de coder pour flash sans être un programmeur aguerri. L’outil a certes gagné en puissance, mais le fait est là : il est de plus en plus rare qu’un concepteur d’application flash puisse être aussi le réalisateur technique de cette application.
Les outils du multimédia interactif (hypercard, director, flash) avaient pourtant été précisément conçus pour permettre à des gens de s’exprimer tout en acquérant les connaissances techniques (bien sûr il en faut un peu) au fur et à mesure. J’ai connu par exemple un vieux barbon universitaire qui, dans son coin, bricolait un cd-rom sur un sujet historique qui le passionnait. Il était autonome même s’il lui a fallu un « pro » (moi en l’occurrence) pour rendre le contenu un peu plus solide techniquement parlant. Aujourd’hui, il n’y aurait pas d’outil off-line pour lui (en revanche il peut faire un blog par exemple, mais là il sera dépendant du format blog qui ne convient pas forcément dans son cas).

[Reply]

« Et c’est une chose heureuse car il faudrait 10 ans à un ingénieur pour arriver au niveau d’un Didier en Java ! »

Au contraire, il mettra sans doute bien plus de temps que ça s’il n’aime pas ou n’est pas amené à mettre les mains dans le camboui. Je suis jeune, mais combien de fois ai-je vu des personnes se trouver devant un programme foireux, et incapables d’en analyser le contenu parce qu’ils n’ont fait qu' »assembler des briques ». Et qui vont déléguer à d’autres l’analyse du problème parce qu’ils ne savent plus faire et qu’on leur a dit que c’était plus leur problème.

Au contraire de ce point de vue, autant assembler des briques nécessite quelques connaissances et de l’expérience (savoir bien choisir entre deux modules le meilleur pour faire une tache), autant la personne qui va assembler ces briques ne sera plus qu’un architecte de bas étage, parce qu’il ne saura pas ce qu’il y a derrière tout ça.

[Reply]

Au risque d’être dans les derniers vieux cons je pense que l’école doit continuer de former au fonctionnement des systèmes.
Un ingénieur auto doit savoir comment marche une voiture (moteur…), un architecte dans le bâtiment connaître la résistance des matériaux… On ne peut pas tout le temps se reposer sur les outils.
Il n’y a qu’en informatique ou la connaissance des ingénieurs est inférieure aux utilisateurs.
Savoir comment marche un processeur, un disque, comment écrire son propre langage, sa propre base de données … même en miniature permet ensuite de mieux comprendre comment ca marche dans les produits et donc de faire des choix des conception de meilleure qualité. Le fait de savoir comment ca marche ne veut pas dire qu’ensuite sur projet on doit réécrire son serveur web ou sa base !
de plus je maintiens qu’en 3 ou 4 ans il est tout a fait possible de développer des couches tout seul : un serveur web de base se code en quelques lignes de code !

Google permet d’accéder a des informations parcellaires pas à la compréhension et c’est bien pour ca que ca se passera mal !

[Reply]

« un serveur web de base se code en quelques lignes de code ! »
=> quand ce n’est pas moins.
Le serveur en question, il suffit de passer par inetd (sous linux). Pour l’application, installation de ruby on rails (par exemple), 4 lignes de commandes, et on a un blog avec commentaires. Où se trouve alors le savoir faire ?

[Reply]

Sur les composants et les ingénieurs qui ne savent plus comment ca marche, lire ou relire les textes par Dewar et Schonberg liés ici :

http://developers.slashdot.org/developers/08/01/08/0348239.shtml
http://developers.slashdot.org/article.pl?sid=08/01/22/0217200

[Reply]

« Et c’est une chose heureuse car il faudrait 10 ans à un ingénieur pour arriver au niveau d’un Didier en Java ! »

C’est une chose heureuse dans l’immédiat, en tout cas pour la rentabilité de son projet, le problème est que 10 ans après, le malheureux sera toujours loin d’être au niveau d’un « Didier » en java.
Appliquer des framework pendant 10 ans n’apprend jamais… qu’à appliquer des framework.
Je veux bien qu’on me dise que le modèle économique n’a pas besoin de beaucoup de « Didier » mais de beaucoup de jeunes applicateurs de framework. Mais il me parait très exagéré de présenter ça comme l’acquisition de nouvelles compétences.

[Reply]

Je vois que le « Didier » devient l’unité de mesure 🙂

[Reply]

Java a été inventé à cause d’une pénurie d’intelligence dans le développement
Java est assez pauvre comme langage mais très bien pour sous traiter à pas cher le kilo

[Reply]

 

Répondre à Dominique Rabeuf Annuler la réponse

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.