Developpez.com

Une très vaste base de connaissances en informatique avec
plus de 100 FAQ et 10 000 réponses à vos questions

L'informaticien, artisan des temps modernes
Ou le développement est-il plus proche d'un processus industriel ?

Le , par hugo123, Rédacteur
L'informaticien, artisan des temps modernes ?
Non, le processus complet est plus proche d'un processus industriel

Salut,

Je viens de lire à l'instant un billet sur l'informatique et un parallèle avec l'artisanat. C'est un sujet qui revient souvent. 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.

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 concu 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 parralè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 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 reflexion 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 compagnonage. 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 proné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 reflexion 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 reflexion 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) Evidemment 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.

Source originale: un billet sur http://hakanai.free.fr


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Rams7s Rams7s - Membre éclairé https://www.developpez.com
le 27/05/2010 à 11:30
Citation Envoyé par el_slapper  Voir le message
waterfall : cycle en V. Un projet ou, dès le départ, on définit tout ce dont on a besoin. Puis on fait, en une seule passe. Méthode très courante, appliquée un peu partout, parfois de manière très rigide.

Je souhaiterai juste indiquer que waterfall et cycle en V, on ne m'a jamais dit que c'était pareil. Pourtant j'ai eu plusieurs profs venant d'endroits et cultures différentes.

Citation Envoyé par el_slapper  Voir le message
la méthode, c'est important, mais tant que c'est appliqué par des gens qui ne comprennent rien, en fait, c'est juste du blabla.

Pour ça que dans les méthodes agiles ils disent qu'ils faut des gens compétents. Ils se mouillent pas trop...
Avatar de el_slapper el_slapper - Expert éminent sénior https://www.developpez.com
le 27/05/2010 à 14:46
Citation Envoyé par Rams7s  Voir le message
Je souhaiterai juste indiquer que waterfall et cycle en V, on ne m'a jamais dit que c'était pareil. Pourtant j'ai eu plusieurs profs venant d'endroits et cultures différentes.

j'ai péché par imprécision. Le cycle en V est une forme de waterfall. Comme je n'ai jamais pratiqué les autres.....

Citation Envoyé par Rams7s  Voir le message
Pour ça que dans les méthodes agiles ils disent qu'ils faut des gens compétents. Ils se mouillent pas trop...

Jamais lu ça, mais ça ne m'étonne pas. Parceque bon, évidemment, si on prend une tanche en waterfall et un génie en agile, bizarrement, l'agile sera supérieur
Avatar de LSRouge LSRouge - Membre régulier https://www.developpez.com
le 27/05/2010 à 14:47
Une Tanche restera une tanche ... quoi qu'on lui demande ...nan ?
Avatar de hugo123 hugo123 - Rédacteur https://www.developpez.com
le 27/05/2010 à 15:14
Pas toujours, parfois c'est juste qu'on les emploie pas pour la bonne chose.
J'ai déjà vu des gens bons dans un contexte et moins dans un autre.

Bon mais des fois c'est vrai que...
Avatar de LSRouge LSRouge - Membre régulier https://www.developpez.com
le 27/05/2010 à 15:17
Moi , j'appelle cela un Boulet ...

Mais comme on est toujours le Con de quelqu'un ... on peut toujours etre aussi le Boulet de quelqu'un ..?
Avatar de Astartee Astartee - Membre éclairé https://www.developpez.com
le 27/05/2010 à 15:57
Le tour qu'a pris cette discussion me fait assez penser à celle-ci, et particulièrement à ce message.

Les génies seront toujours des génies.
Les boulets seront toujours des boulets.
Pour les moyennement bons et moyennement motivés sans prétentions, le fait d'être encadrés par une "école" ou par un "processus qualité" peut grandement aider...
Avatar de LittleBean LittleBean - Membre averti https://www.developpez.com
le 27/05/2010 à 18:23
Je me sens obligé de réagir là

Conclusion, toujours la même : la méthode, c'est important, mais tant que c'est appliqué par des gens qui ne comprennent rien, en fait, c'est juste du blabla.

Pas vraiment d'accord ... je suis plutôt :

Pour les moyennement bon et moyennement motivé sans prétention, le fait d'être encadrés par une "école" ou par un "processus qualité" peut grandement aider...

Quand on arrive dans le monde du travail on est pas prêt à bosser à un niveau professionnel, heureusement que l'on peut s'appuyer sur des méthodes et des processus qui peuvent nous encadrer...

Ah oui je vois le genre d'informaticien industriel : celui qui parle comme dans les services commerciaux et marketing et se prend pour un trader, celui qui utilise des frameworks de 300 Mo pour livrer un utilitaire de 2Mo, celui qui utilise les usines à choucroute Java pour faire un hello world et enfin ceux qui construisent des applications en ligne sans même savoir ce qu'est du HTML ou encore ceux qui modélisent de la base de données en UML, oui je vois le genre d'informatique industrielle qui se profile.

Ce n'est pas parce qu'on connait des concepts que l'on est obligé de les suivre à la lettre, tandis que si tu ne les connais pas ... pas de risque...
Par exemple : ce n'est pas parce que tu utilises une modélisation UML pour générer ta base ou ton code que tu ne sais pas faire du java ou du sql ...

A ce sujet, j'ai vu, au cours de mon passage chez un éditeur de logiciel, une guerre absolue des "anciens" contre les "nouveaux", avec une mauvaise foi totale des deux cotés.


La vérité est .... souvent entre les deux
Tu oublies ceux qui refusent toute méthode entre le petit jeune "nan mais c'est clair là ma variable x elle fait ça et couplée avec i,e,f on obtient r" qui refuse de faire des efforts et le vieux de s'adapter "nan mais c'est pourris ton svn ça marche pas ... je t'envoie un zip en te disant ce qui a changé et tu copies/colles ..."

On a introduit des méthodologies pour pouvoir travailler à plusieurs selon différents contextes. Une méthodologie n'est qu'un regroupement de "best practice" pour un contexte particulier le tout guidé par une orientation générale ....

Il n'y a pas de mauvaises méthodologies seulement des choix inadaptés aux besoins

Un artisan par définition travail seul, tandis que l'industriel mis sur la masse ... il suffit de compter avec combien de personnes vous travaillez au quotidien pour savoir de quel bord on est !!
Avatar de souviron34 souviron34 - Expert éminent sénior https://www.developpez.com
le 29/05/2010 à 18:21
Moi j'ai déjà exprimé souvent mon opinion, et je pense qu'on est (et devrait) être plus proche de l'artisanat que de l'industrie...

Un débat de référence dans lequel beaucoup de points sont soulevés (et d'intervenants se sont exprimés) est :

Projets informatiques : Les Bonnes Pratiques

et ce post où j'expose mon point de vue.

Avatar de hugo123 hugo123 - Rédacteur https://www.developpez.com
le 31/05/2010 à 13:41
C'est amusant mais ton point de vue rejoint les méthodologies lean et agiles. Même si tu n'aimes pas le mot "méthodologie", qui pourtant n'est rien d'autre qu'une recette de cuisine ou un pattern, ce que tu évoques :
- la reconnaissance des connaissances (ne pas parler de ressources humaines comme si elles étaient interchangeables)
- prendre des bons (ou tout du moins leur donner les moyen de le devenir)
- faire des équipes pluridisciplinaires
- inclure le métier dans l'équipe

fait partie intégrante des méthodologies agiles/Lean.

En tout cas pour ce que je lis des personnes qui ont réagi ici, plusieurs partagent ce même point de vue, c'est avant tout les compétences personnelles qui font un projet réussi. C'est en partant de ce constat que vous comparez l'informatique à l'artisanat. C'est bien ça ?

Autre point que je crois comprendre en lisant les avis ci-dessus, la réussite d'un projet étant lié aux qualités des personnes, les standards ne sont pas importants (ou pas primordiaux en tout cas).

Pour ma part je ne suis pas sûr que la qualité individuelle fasse partie de la définition de l'artisanat. On peut être bon quelque soit la façon de bosser. On peut être bon dans un contexte et pas dans un autre, d'où la nécessité d'être employé à bon escient comme le souligne souviron34.
En tout cas le fait de dire "les projets qui marchent reposent sur les individus", je partage largement. Mais ce n'est pas pour autant que je fais la liaison avec la façon de bosser.

Quant aux standards (méthodologies, normes, etc...) partant du simple fait que la majeure partie des appli passe 80% de son temps en maintenance et reste rarement aux mains de son/ses créateurs, je pense qu'ils sont importants. Comme dit plus haut :

Pour les moyennement bons et moyennement motivés sans prétentions, le fait d'être encadrés par une "école" ou par un "processus qualité" peut grandement aider...

Ça vaut aussi pour les bons qui débarquent sur un projet et qui aiment y trouver une structure qu'ils ont déjà vu.
Avatar de el_slapper el_slapper - Expert éminent sénior https://www.developpez.com
le 31/05/2010 à 14:12
Citation Envoyé par hugo123  Voir le message
(.../...)

Quant aux standards (méthodologies, normes, etc...) partant du simple fait que la majeure partie des appli passe 80% de son temps en maintenance et reste rarement aux mains de son/ses créateurs, je pense qu'ils sont importants. (.../...)

Sur ce point, parce que sur le reste, on se répète tous.....(sans être à des kilomètres, d'ailleurs)

Le truc, c'est que je ne vois pas comment une méthodologie peut préparer à faire un code maintenable. Je n'ai pas dit propre (ça , c'est faisable), j'ai dit maintenable. Celui qui n'a jamais fait de maintenance ne peut pas savoir quel effet ça fait de déterrer un code de 35 ans d'âge. Et d'y voir la fière structure du fier développeur qui croit avoir fait un truc maintenable, et en fait a pondu une horreur intouchable. Parce qu'il ne savait pas. Moi aussi, je suis passé par là, j'ai fait de la surencapsulation pour faire plus propre, et j'ai rendu illisible un programme de même pas 150 lignes(avec 6 niveaux d'encapsulation).

Le bon niveau d'encapsulation(parmi d'autres), il ne se définit pas, il se sent, avec l'expérience. L'expérience de la maintenance. Tant qu'on fait du projet, on se prend(à tort, et j'ai pratiqué) pour le roi du monde.
Avatar de hugo123 hugo123 - Rédacteur https://www.developpez.com
le 31/05/2010 à 14:55
Tout a fait d'accord, la notion de maintenable n'est pas évidente, surtout qu'on a tous la désagréable habitude de pester sur le travail des mecs précédents ^^

Mais maintenable des fois c'est juste faire preuve de bon sens, c'est avoir une norme de codage standard (les normes SUN par exemple en JAVA), l'utilisation de design pattern standard avec un nom qui correspond bien à ce que ça fait (une classe qui s'appelle une factory doit fabriquer des objets et pas faire autre chose). C'est aussi avoir un logiciel d'intégration continue qui tourne avec un bon harnais de test, c'est d'avoir des procédures qualité (revue de code par exemple) etc...
Un truc tout bête, j'arrive sur un projet JAVA, ils utilisent Maven et ont donc respecté le SDL (standard directory layout), je sais tout de suite comment monter mon projet sous eclipse, où sont les sources, où sont les tests et mes informations de builds. Ça ne veut pas dire que je suis autonome, mais ça aide grandement.

Quant à la méthodologie, dans une méthode itérative vu qu'on retouche souvent aux mêmes trucs, si on n'automatise pas les tests, le build et qu'on oublie les tests où qu'on ne maitrise pas les outils de refactoring de son IDE préféré, c'est vite difficile. Du coup on apprend à le faire, poussé par la méthode.
Offres d'emploi IT
Architecte technique des systèmes d'information H/F
Safran - Ile de France - Évry (91090)
Ingénieur intégration, validation, qualification du système de drone H/F
Safran - Ile de France - Éragny (95610)
Ingénieur H/F
Safran - Ile de France - Moissy-Cramayel (77550)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil