Discussion :

[hugo123]

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 :

• les premiers prototypes issues de l'esprit de précurseurs. On est alors dans une phase où la construction automobile est proche de l'artisanat au sens où le travail est manuel et sans aide automatisée et repose sur quelques individus.
• l'arrivée du taylorisme et fordisme qui font que "les artisans d'une industrie de luxe réservée à des privilégiés deviennent progressivement des ouvriers spécialisés d'un produit banalisé pour le grand public."
• la mise en avant du toyotisme qui "se base à nouveau sur les compétences et la qualification des ressources humaines"

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 :

• en lean : le cercle de qualité
• "Bâtissez le projet autour de personnes motivées" et "Une attention continue à l'excellence technique et à la qualité de la conception" (Cf. http://fr.wikipedia.org/wiki/M%C3%A9...gile#Principes)

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

[el_slapper]

Aucune comparaison n'est pertinente à 100%. Néanmoins, je pense qu'on est à l'intermédiaire entre l'artisanat pur et l'équipe de R&D industrielle.

L'erreur fondamentale, à mon sens, n'est pas de parler d'industrie, mais de se tromper d'échelon : on est toujours en R&D. Parcequ'en informatique, une fois le produit conçu et validé, la suite est facile : on copie/duplique/installe...... Quand je bossais en R&D automobile, une fois le produit R&D conçu, il restait des milliards d'étapes(hormis trouver les clients) : créer un moule "de production", mettre en place les gammes de fabrication, gérer la qualité de chaque pièce(et non pas simplement du design en lui-même), trouver des améliorations de méthodes pour augmenter la productivité, etc..... Toutes ces étapes n'ont pas vraiment de sens en développement logiciel : mon truc il est prêt, je le livre en prod/à graver/que sais-je.

Le Toyotisme est une comparaison interessante, mais limitée : les opérateurs fabriquent toujours la même voiture. On ne fabrique jamais deux fois le même logiciel, on fait Ctrl-C Ctrl-V......

Fabriquer un moule d'injection thermoplastique, c'est un travail à plusieurs centaines de K€. Faire un "gold" ou livrer une évolution en prod, non. Le produit sorti de R&D est déjà quasiment fini en informatique. Les comparaisons avec la suite du processus industriel me paraissent donc déplaçées.

[hugo123]

on est toujours en R&D. Parcequ'en informatique, une fois le produit conçu et validé, la suite est facile : on copie/duplique/installe...... Quand je bossais en R&D automobile, une fois le produit R&D conçu, il restait des milliards d'étapes(hormis trouver les clients) : créer un moule "de production", mettre en place les gammes de fabrication, gérer la qualité de chaque pièce(et non pas simplement du design en lui-même), trouver des améliorations de méthodes pour augmenter la productivité, etc..... Toutes ces étapes n'ont pas vraiment de sens en développement logiciel : mon truc il est prêt, je le livre en prod/à graver/que sais-je.

En fait je ne compare pas les mêmes étapes. Selon moi la conception effectuée en bureau d'étude automobile correspond à la phase de specs dans le projet informatique et non la phase de specs + la réalisation.
Donc après cette phase de R&D, on a bien les miliards d'étapes dont tu parles : créer un cadre de travail, gérer la qualité du logiciel, l'assemblage etc...

Quant au toyotisme, la comparaison n'est pas de moi ^^ C'est la vision Lean qui a été transposé justement et qui compare les processus. La comparaison c'est surtout que dans le toyotisme on tend vers des ateliers tout intégré (le fameux cercle de qualité) qui est complètement autonome. On a la même chose avec les équipes Lean et agile qui pronent des équipes pluridisciplinaires et auto organisé.

Le produit sorti de R&D est déjà quasiment fini en informatique.

Non loin de là, ou bien on ne parle pas des mêmes choses. La R&D en informatique c'est la conception, éventuellement le maquettage (POC etc...) mais ce n'est pas la réalisation. Enfin tout du moins dans la façon dont j'aborde les choses ce n'est pas dans la R&D que je range la réalisation.
Effectivement dans un projet "exploratoire" où la solution technique est créée pendant la phase de réalisation (comme ça peut arriver en agile) alors oui, la R&D est confondu avec la réalisation. Mais dans un projet en cascade, la conception est séparée de la réalisation.
Et puis même réalisé, il reste encore beaucoup de choses à faire, l'intégration, le packaging etc...

[cbleas]

Bonjour,

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)

Je me reconnais assez ici.
est ce négatif. j'en suis pas certain alors que je vois la majorité de mes concurrents créer des logiciels techniquement beau mais qui 3 ans après la sortie ne sont toujours pas débugué à 100% pourtant ils ont testé retesté.
il faut alors attendre la nouvelle version qui sera à nouveau buggée.

Pour ma part si j'ai un bug dans mon application je debugge tout de suite et la version est à jour. Si un de mes clients me demande une modif je la rajoute et les autres en profitent. En un mot je m'amuse à faire mon métier et en répondant aux attentes de mon client.

Contrairement aux nombreux informaticiens que l'on rencontre sur ce site et qui parfois on marre de faire des lignes de code pour faire des lignes.

Bizarrement souvent les codeurs les plus heureux sont ceux qui se sont mis à leur compte donc devenus artisan de leur métier.

bonne journée

[tnntwister]

Déjà le sujet est à mon avis mal fixé : l'Informatique. C'est comme quand on demande à un développeur d'assembler un pc ou de le dépanner, parce que c'est son boulot, il est "informaticien".

Pour ce qui est du développement web, je pense que beaucoup de tes exemples ne collent pas, parce que tu imagines des trop gros développements. Un site internet simple peut être réalisé en deux jours, avec ou sans code propriétaire. Ceci dit, moi qui me voyais comme un artisan, j'ai bien aimé ton article, parce qu'il y avait justement plein d'aspects négatifs dans le terme que je n'avais pas envisagé.

Je suis assez d'accord avec cbleas, c'est souvent les artisans du développement qui sont les plus heureux de leur travail. Reprendre le code des autres de toute facon c'est rarement un plaisir, avouez-le...

[bubulemaster]

Bonjour,

je pense qu'on est dans l'air industrielle pour ce qui est progiciel (Office, Nero...)

On est dans l'artisanat pour ce qui est du sur mesure (développement client) avec incorporation de processus industriel pour les tâches répétitives.
Avec comme inconvénient parfois, on développe un sur-couche à un framework industriel pour l'adapter à notre besoin et c'est très lourd à faire évoluer le framework.

Mais, bon, je pense qu'effectivement, l'aire bidouilleur Bill Gates, Linus... ça devient de plus en plus dur face aux industries

en tout cas, très bon sujet

[JMarshall]

bubulemaster m'a devancé...en effet dès le début de la lecture de cette article, je me suis dit qu'il était étonnant d'essayer de qualifier l'ensemble du développement informatique comme artisanal ou industriel alors qu'il me semble évident que c'est deux conceptions ne sont pas des disciplines différentes mais simplement des approches divers de la production.

Il existe donc comme dans tous domaines, des artisans et des industriels qui ne différent pas par le but mais par les moyens (pas seulement financiers) de l'atteindre.
Ainsi je pense qu'un "artisan informatique" pourra produire un produit de qualité équivalente ou supérieure à un industriel mais dans des délais et en proposant des services différents.

EDIT: j'ai oublié d'ajouter que ma conception de l'artisanat se base surtout sur le fait de suivre le processus de production, de la conception à la diffusion...

[hugo123]

Déjà le sujet est à mon avis mal fixé : l'Informatique. C'est comme quand on demande à un développeur d'assembler un pc ou de le dépanner, parce que c'est son boulot, il est "informaticien".

C'est un terme volontairement générique. Difficile de regrouper toute la profession sinon. Entre expert métier, technique, support, test et les différentes formations possibles, j'ai pas vu mieux comme terme ^^

Pour ce qui est du développement web, je pense que beaucoup de tes exemples ne collent pas, parce que tu imagines des trop gros développements.

Pas faux, surement parce que j'ai bossé en SSII pour des grands comptes, puis pour un éditeur de logiciel puis enfin pour une boite d'assurance dont le site est assez imposant. Je n'ai pas pris en compte dans cet avis le développement personnel.

Je me reconnais assez ici.
est-ce négatif. j'en suis pas certain alors que je vois la majorité de mes concurrents créer des logiciels techniquement beau mais qui 3 ans après la sortie ne sont toujours pas débugué à 100% pourtant ils ont testé et retesté.
il faut alors attendre la nouvelle version qui sera à nouveau buggée.

Grand débat ^^ Réutilisation, tests, découplage, standardisation, chacun de ces items mériterait une longue discussion. Tout ce que je peux en dire je le ferais avec une citation d'audiard que j'ai trouvé excellente sur le contexte :
"Les conneries, c'est comme les impots, on finit toujours par les payer"

La version plus light et plus connue :
"La dette technique, on finit toujours par la rembourser, avec intérêt"

Mais oui, à un instant, il n'est pas impossible que ça marche bien, ou pas selon certains facteurs externes (dans ton cas, ta capacité à le maintenir semble bien fonctionner).

Bizarrement souvent les codeurs les plus heureux sont ceux qui se sont mis à leur compte donc devenus artisan de leur métier

.

Héhé, je suis à mon compte, mais je ne suis pas artisan ^^ Etre à son compte ne veut pas dire que l'on fasse ce qu'on veut. Je fais le même métier que la plupart ici (mais pour mon compte).

[tHE_fLAmMinG_mOE]

Un très bon billet

[Invité]

Cette question en dit long aussi sur celui qui la pose.

C'est quoi la différence entre artisanat et industrie ? n'est-ce pas une insulte déguisée, grossièrement traductible par "bidouille grenouille/état de l'art doctor" où le fameux doctor abuse des seconds degrés pour justifier un chèque astronomique ?

Je cherche un gars qui lit couramment les expressions régulières en perl et écrit bien du c embarqué et du dotnet capable d'alimenter une stack tcp/ip embarquée, avec une vue imprenable sur l'ARM 7 , son ethernet, son usb

Là où j'aimerais qu'il soit créatif, c'est que j'ai 4 pistes graphiques synthétiques à l'écran avec leur scrolling horizontal et que j'aimerais bien qu'en cliquant sur une d'elles, elle sélectionne l'élément et synchronise la grille de data dans le coin à gauche.

J'aimerais beaucoup qu'il joue un peu de guitare car moi je suis plutôt clavier et ça permettrait de se détendre en faisant quelques boeufs que je trouve plus utiles que les réunions m'enfin, dans le cas contraire , il pourra toujours fredonner quelque chose.

J'exagère à peine.

Personne et surtout pas en France ne contrôle la VRAIE industrie du logiciel !!
Racontez ce que vous voulez, pétez là vous autant que vous voulez. Le contrôle ne ce situe pas dans l'hexagone , être sérieux est déjà un gros atout, savoir se détendre me semble le plus gros handicap français. Quant à ces distinctions de vocabulaire, elles ne font qu'accroitre le caractère exotique de l'informatique tricolore, son coq, son saucisson, son management issu du BTP, ses réunions flippantes...

[Maximil ian]

Je me demande si une partie de ces débats autour de l'artisanat ne sont pas nés d'un malentendu autour du mouvement Software Craftsmanship.

Ce manifeste issu du monde agile a pour but d'établir une tradition d'excellence technique et d'amélioration continue dans la communauté des développeurs, notamment par le biais d'échanges et d'apprentissage pris en charge par les plus expérimentés.
Il s'agit au final de faire valoir que les développeurs sont de vrais professionnels dont l'avis doit être pris en compte au même titre que tous les autres acteurs d'un projet informatique, et pas juste une batterie de code monkeys qu'on fouette pour livrer dans les temps.

Tout ce que tu évoques Hugo autour de l'artisanat traditionnel (absence d'automatisation, travail à la main, paternité de l'oeuvre entière...) n'est évidemment pas applicable au software craftsmanship que certains appellent artisanat logiciel.

Depuis les années 70, on a essayé de voir le logiciel comme une métaphore du BTP, avec un plan parfait tracé à l'avance et une construction étage par étage. Cette approche a montré ses limites et les méthodes agiles sont nées de ce constat de dysfonctionnement.

Récemment la tendance a été de voir le développement logiciel comme une usine utilisant des moules à projets. Je ne suis pas persuadé que ça soit beaucoup plus adapté dans la plupart des cas.

On essaie maintenant de voir le logiciel à travers le prisme de l'artisanat d'art, mais en tant que contre-exemple pour rappeler des mauvaises pratiques évidentes (au passage enfonçant pas mal de portes ouvertes)... ?

Quand comprendra-t-on que la métaphore est néfaste, que le développement de produits logiciels est une discipline à part entière assez grande pour s'inventer ses principes, ses codes, ses pratiques qui n'ont rien à voir avec ce qui s'est fait avant dans d'autres domaines ?

[el_slapper]

En fait je ne compare pas les mêmes étapes. Selon moi la conception effectuée en bureau d'étude automobile correspond à la phase de specs dans le projet informatique et non la phase de specs + la réalisation.

Et moi je dis que tu ne connais rien à l'industrie(l'informatique, tu as l'air de connaitre, par contre). Dans mes projets de R&D industrielle, j'ai fait retailler des moules, j'ai mis au point des techniques de contrôle, j'ai injecté des thermoplastiques, etc..... Je ne me suis pas contenté de faire des beaux tableaux EXCEL et des beaux dessins sous CATIA. Et c'était toujours de la R&D.

Donc après cette phase de R&D, on a bien les miliards d'étapes dont tu parles : créer un cadre de travail, gérer la qualité du logiciel, l'assemblage etc...

Le cadre de travail en informatique, c'est le gugusse en agence qui vend une assurance vie. Là, oui, ça ressemble aux chaines ou on produit des seaux ou des tableaux de bord.

Quant au toyotisme, la comparaison n'est pas de moi ^^ C'est la vision Lean qui a été transposée justement et qui compare les processus. La comparaison c'est surtout que dans le toyotisme on tend vers des ateliers tout intégré (le fameux cercle de qualité) qui est complètement autonome. On a la même chose avec les équipes Lean et agile qui pronent des équipes pluridisciplinaires et auto organisé.

Sur l'axe qualité, c'est fort possible. Mais je persiste à dire que la finalité est différente : l'équipe Toyota fabrique toujours la même voiture, et n'a pas à se préoccuper de la manière dont marche sa voiture. Tous les développements, absolument tout, altèrent le fonctionnement même du produit fini. Ils sont donc de la R&D

Non loin de là, ou bien on ne parle pas des mêmes choses. La R&D en informatique c'est la conception, éventuellement le maquettage (POC etc...) mais ce n'est pas la réalisation. Enfin tout du moins dans la façon dont j'aborde les choses ce n'est pas dans la R&D que je range la réalisation.

Et moi je répète que ta vision industrielle est fausse. La R&D, c'est recherche et développement. Recherche, c'est le POC : "si on faisait un phare avec un conduit optique en fibres de verres, sans lentilles?". Et quand on a un phare qui marche, la Recherche s'arrête. Le Développement, c'est recevoir une commande d'un fabricant qui veut un phare à fibres de verre pour son prochain modèle, dessiner les pièces et les outillages, définir les gammes de production. Et, une fois que la chaine est prête à commencer, avec les appros, les machines, les opérateurs, on peut commencer la montée en charge. C'est là que s'arrête le D de R&D.

Et, pour moi, ça correspond exactement à mon boulot de développeur. Il m'arrive de faire de la recherche(tiens, comment générer du XML en Cobol sans passer par l'ordre XML GENERATE trop rigide? Comment refondre cette chaine pour uniciser les garnissages? Comment trafiquer cet historique pour supprimer les doublons de janvier?), mais pour l'essentiel, je fais du développement; par exemple, là, je dois créer un suivi marketing pour un nouveau produit bancaire. La recherche est déjà faite depuis mathusalem(on imite les autres produits), mais je vais développer : modifier les tables de paramètres, coder les spécificités du produit, tester unitairement le bon fonctionnement du programme, puis tester la chaine dans son ensemble. Là seulement, je vais laisser la main(et ça ne sera plus du développement) : des gens vont tester, valider, et on va monter en prod, ou seront produites tous les mois des campagnes marketing pour ce produit.

Effectivement dans un projet "exploratoire" où la solution technique est créée pendant la phase de réalisation (comme ça peut arriver en agile) alors oui, la R&D est confondu avec la réalisation. Mais dans un projet en cascade, la conception est séparée de la réalisation.

comme la recherche est séparée du développement.

Et puis même réalisé, il reste encore beaucoup de choses à faire, l'intégration, le packaging etc...

le packaging, ça n'est plus du développement. Moi je parle de développement. Effectivement, le packaging est une phase industrielle pure.

L'intégration : soit il y a des adhérences, soit il y en a pas. Le développeur(encore lui) doit s'assurer qu'il n'y en a pas, ou bien les gérer. Au pire, laisser à l'intégrateur les billes pour gérer. Ça reste très artisanal, à mon sens.....

[el_slapper]

(.../...)Récemment la tendance a été de voir le développement logiciel comme une usine utilisant des moules à projets. Je ne suis pas persuadé que ça soit beaucoup plus adapté dans la plupart des cas.(.../...)

+1

le moule, c'est le logiciel développé. Qui permet de mouler le DVD dans son package.

[LSRouge]

Hello

Dans ma petite boîte, on fait de la bidouille ! Enfin, en interne.
Quand un collegue a besoin d'une petite appli pour lui faciliter la vie, on y passe un ou deux jours maxi, entre deux autres taches, on le teste et on lui donne ! On sait rapidement si ça bugge et on corrige rapidement.
Pour les clients, on a des demandes souvent specifiques, on les gère au coups par coups, en fonction de la demande. Là aussi, on test... faut mieux.
Est ce de l'artisanat ??

Le côté industriel, je l'ai connu dans une grande boîte. Chacun a son appli en maintenance, ses capacités ... c'est plus "carré".

Est la taille de la boîte qui donne son côté artisanal ou non à l'informatique qui y est pratiquée ? Peut-être !

A+

LSR.

[hugo123]

@el_slapper


Effectivement, ma vision de l'industrie est sommaire, je ne prétends pas le contraire d'ailleurs. Mais ma comparaison était beaucoup plus macro et je ne cherche pas à faire cadrer chaque étape pour établir cette comparaison, ce serait trop hasardeux.

Mais d'un point de vue macro, la où je vois une chaine de production c'est par exemple quand je vois un schéma classique de cycle en v :



(Ou en cascade si on préfère : http://en.wikipedia.org/wiki/File:Waterfall_model.svg)

En lisant d'ailleurs la définition du waterfall sur wikipedia on y lit ceci :

The waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.

La comparaison n'est donc pas récente, le terme lui-même vient des chaines de production et a été formalisé par Royce en 1970.

Quant à la comparaison entre toyotisme et Lean, elle vient que les deux vont traiter des mêmes pratiques (le lean n'est qu'une déclinaison dans l'informatique). Le vocabulaire est identique (kanban, kaizen, muda etc...) et on va utiliser des représentations identiques pour représenter les flux de production : flow chart par exemple.

[el_slapper]

Ah mais je n'ai jamais dit que le waterfall était mauvais. Il est juste adapté à certains cas précis. Mais que les anciens, malgré toutes leur sagesse, aient fait une comparaison avec l'industrie dont il venait ne signifiait pas pour autant qu'ils avaient raison. Le taux important d'echec des projets en waterfall(souvent liés à une conception imprécise, ecueil que tendent à corriger les méthodes agiles) me fait penser qu'ils avaient tort, en fait.

Quant à lean, je ne connais pas assez. Mais si'il utilise le kanban(les post-it posés au tableau), c'est d'une manière radicalement différente de l'entreprise toyotiste, qui elle pose une etiquette(toujours la même) sur une caisse de pare-chocs, et utilise cette étiquette, une fois la caisse vide, pour commander une nouvelle caisse. C'est une appropriation de vocabulaire, pas de méthodes. Chaque post-it est différent. Chaque kanban est identique.

[zencorp]

En tout cas, développeur artisanal ou industriel, l'avantage et que cela permet à tout un chacun d'accéder au développement et de proposer ses produits, comme le petit artisan qui aura une production à discrétion qui avec le temps pourra proposer une production à plus grande échelle ou intégrer une grande compagnie.

[hugo123]

Ah mais je n'ai jamais dit que le waterfall était mauvais. Il est juste adapté à certains cas précis. Mais que les anciens, malgré toutes leur sagesse, aient fait une comparaison avec l'industrie dont il venait ne signifiait pas pour autant qu'ils avaient raison. Le taux important d'echec des projets en waterfall(souvent liés à une conception imprécise, ecueil que tendent à corriger les méthodes agiles) me fait penser qu'ils avaient tort, en fait.

Je partage cet avis, je l'indique d'ailleurs dans le premier post. Je suis plus porté sur les méthodes agiles qui elles ont bien été formalisé par des professionnels de l'informatique et qui prennent en compte les spécificités de ce métier.

Quant au lean, ce qui est intéressant c'est de voir comment il a été théorisé pour justement en extraire l'essence de ce qui marche pour pouvoir le transposer.

- Le kaizen (rien dans sa définition n'est propre à Toyoto, pourtant c'est bien de là qu'il vient)
- Le Kanban dont le principe repose sur la théorie des contraintes et qui donc peut être transposé sans que le métier sous jacent soit identique. (Peu importe que les fiches soient les mêmes ou non, ce qui est important c'est de mesurer le débit et d'adapter les maillons de la chaine).
- La lutte contre le gaspillage (Muda), qui là encore se transpose facilement

[highleaf]

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 utlitaire 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.

Dans tous les cas, on industrialise pour pouvoir interchanger facilement les hommes, réaliser des économies d'échelles et à terme pour tous les informaticiens, se taper des boulots de merde inintéressants et sous payés, voilà le but de l'industrie logicielle.

C'est joli d'appliquer les mêmes principes à 2 centimes qui dirigent notre monde depuis 30 ans mais je rappelle que ces grands principes industriels capitalistes ont prouvé leur limites que nous voyons tous les jours, tous et dans tous les domaines.

Enfin et pour rappel, tous les grandes "avancées" ou "innovations" informatiques sont issues à 90% de petits artisans dans leur garage avec un esprit geek/hacker/artisan des années 80 (google, facebook que vous adorez tellement, stallman, gates...) pas les SSII de la world co à la GFI, unilog et tutti quanti.
(cf : http://www.internetactu.net/2010/05/...netActu.net%29)

Et non, construire un logiciel ce n'est pas construire une voiture ou un téléphone, un logiciel fait appel à de l'intelligence, c'est comme une oeuvre littéraire. C'est dingue de tout réduire à un monde d'objets que l'on doit consommer pour soutenir notre chère croissance en mousse. Quand est-ce qu'on parle de l'industrie littéraire et de l'industrie de la santé ? Je sais ça choque mais on y aussi

[tnntwister]

C'est bien de connaître les théories, mais c'est bien de pouvoir s'en détacher aussi pour avoir une intelligence de terrain et penser par soi-même. C'est peut être ca l'approche artisanale aussi

Juste pour dire que je ne connais aucun des termes techniques que tu cites, et j'ai pas l'impression de faire autre chose que de l'informatique (du moins je code toute la journée). C'est bien d'avoir une vision d'ensemble, mais tu ne peux pas renfermer dans une seule théorie toutes les applications de l'informatique. C'est là que la distinction industrie / artisanat a ses limites, si tu essaies de démontrer sur chaque exemple pourquoi il vaut mieux être industriel qu'artisanal, tu vas te prendre des milliers d'arguments en retour...