Discussion :

[kilroyFR]

Je ne vous connais pas, vous n'aurez peut être rien a faire de mon feedback, mais je vous conseille de faire une introspection forte de votre manière de travailler, de l'image que vous vehiculez, etc... Demandez juste des feedback par exemple tous les 6 mois 2 ou 3 fois de suite. Et réagissez par un plan d'action aux difficultés remontées. Vous serez je pense étonné de la justesse de certains retour, et surement de leur coté généralisé.

Bon courage si vous prenez ce chemin, il va être dur à suivre et difficile à encaisser... mais dans 18 mois je peux vous promettre que vous serez à un tout autre niveau professionnel.

lol, non je ne m'en fous pas mais je le trouve bien naif et vous n'ecoutez pas; cela fait 22 ans que je suis dans l'informatique; a cette epoque les devs etaient interessés par la finalité de qu'ils faisaient et ne s'arretaient pas au langage/techno/outils.
Aujourd'hui c'est l'inverse; j'ai vu le changement au fil des années. La techno/outils/methode est presque considérée comme une fin en soi; ou l'on se retrouve face a des gens pleins de dogmes et d'ideologies. Combien de fois on a entendu des discours de cours de maternelles (java vs c#, oracle vs sqlServer etc.) sans aucun interet.
Visiblement vous ne lisez pas ce que j'ai ecrit. Tout ce que vous proposez a ete testé; en vain, on ne peut pas changer la nature d'un dev qui aura naturellement tendance a faire ce qui l'interesse. Si on est arrivé a cette conclusion c'est le resultat de multiples tentatives, ajustements pour se rendre compte de l'echec. On veille a la bonne communication et on reste a leurs ecoute mais en aucun cas ils ne derogent a ce qu'ils sont censés faire.
La seule chose qui fonctionne c'est ce qu'on a mis en place, juste un constat sur ces 6 dernieres années. Pas besoin de perdre 18 mois pour constater que ca ne fait rien avancer.
J'ai encaissé largement plus de choses que ce que vous pouvez sous entendre.
Le turn over ? ce n'est plus un probleme. l'expertise d'un dev ? ce n'est plus une contrainte.
Et non je ne prends personne de haut, je ne fais que constater la realité; un developpeur (codeur) reste un ouvrier dans l'echelle des professions en informatique; que votre ego vous interdise de le penser ou pas. C'est la profession la plus facile a uberiser et les archis modernes le permettent avec une grande facilité sans risques (contrairement a ce qu'on realisait auparavant).
Est-ce qu'on demande a un ouvrier sur une chaine de production de connaitre comment fonctionne une voiture ? non on lui demande de bien faire la 'micro' tache qui lui incombe.
Pour les archis micro service c'est le meme principe. La production de logiciel est une industrie comme une autre.

[Pyramidev]

Parmi les principes sous-jacents au Manifeste agile, on a :

• Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
  (C'est moi qui mets motivé en gras.)
• Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées.

Mais, pour que ça marche, il faut des développeurs à la fois compétents et motivés pour répondre au besoin.
À l'embauche, comment distinguer de manière la plus fiable un candidat qui cherche à répondre au besoin d'un candidat je-m'en-foutiste ?
Il ne faut pas que les je-m'en-foutistes deviennent majoritaires. Sinon, ça sera contagieux.

D'ailleurs, kilroyFR, quelle est la méthode de recrutement de ton entreprise ? Peut-être qu'il y a eu à la fois un problème de recrutement et de la malchance.

[kilroyFR]

Parmi les principes sous-jacents au Manifeste agile, on a :

• Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
  (C'est moi qui mets motivé en gras.)
• Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées.

Mais, pour que ça marche, il faut des développeurs à la fois compétents et motivés pour répondre au besoin.
À l'embauche, comment distinguer de manière la plus fiable un candidat qui cherche à répondre au besoin d'un candidat je-m'en-foutiste ?
Il ne faut pas que les je-m'en-foutiste deviennent majoritaires. Sinon, ça sera contagieux.

D'ailleurs, kilroyFR, quelle est la méthode de recrutement de ton entreprise ? Peut-être qu'il y a eu à la fois un problème de recrutement et de la malchance.

On leur faisait passer des tests techniques avec nos experts des differentes technos et on avait une idée de leur niveau/motivation. Avec le temps on s'est rendu compte qu'il valait mieux se mefier des gens qui touchent un peu trop a tout car c'est source non pas de curiosité mais plutot d'eparpillement.
Mais effectivement au depart on avait des candidats venant de startups qui ne savaient dire que 'ON a fait ceci, ON a fait cela'. En grattant un peu on se rendait bien compte que le ON n'etait pas lui mais l'equipe. Ca c'est caracteristique en entretien. Le gars parle comme s'il etait encore en equipe.
Du coup un beau CV mais un contenu technique personnel ... vide. A l'usage on prefere maintenant des gens interessés par le metier et moins par la techno (on ne cherche pas a courir derriere la derniere techno a la mode ou derniere lib microsoft (ca a ete cause de problemes quand on travaillait en environnement WPF/MEF etc.).
Bon, comme on est en archi micro service et qu'ils suivent des patterns on a largement simplifié le niveau de connaissances techniques requises donc plus de facilité a trouver des candidats. Vous pouvez chercher quelqu'un d'ultra pointu sur un sujet mais aucun interet d'avoir N developpeurs tous pointus sur tous les sujets. C'est introuvable, ca coute cher et ca ne fait rien gagner.

[Gluups]

Bonjour,
Je livre mon expérience de vouloir faire le travail sois même.
N’étant pas développeur professionnel j'ai décidé il y a quelques années de développer moi même un programme spécifique.
Il s'agit du domaine de la navigation maritime plus précisément de Astro-navigation, car demander a un programmeur de vous faire un tel logiciel nécessite une présence (professionnellement compétant) pour épauler celui qui écrit le code, reste le test (débogage) qui demande pratiquement autant de temps que l’écriture du code.
Sauf que je ne suis pas encore sorti de l'auberge, c'est pour cela que j'ai utilisé le mot "épauler un programmeur professionnel".
les applications spécifiques sont toujours compliquées et longues a réaliser surtout quand il s'agit de sortir des sentiers battus.

En effet, pour des choses bien pointues il n'y a rien de tel que la double compétence. On n'en est pas encore tout-à-fait là à ce que je comprends ? Ça peut venir, c'est souvent comme ça que viennent les vocations.

En attendant, le succès dépendra d'une bonne entente entre les deux personnes, qui les aidera à mieux se comprendre, tout en soutenant leur motivation.

La difficulté, pour se replacer dans le fil de la discussion, est que probablement aucun des deux n'a de vague idée de combien il faudra de temps pour finir le projet (sauf à avoir fait au départ une présentation très efficace du besoin). Il reste donc à espérer que ça ne dépassera pas les moyens qui pourront être dépensés dessus.

[Gluups]

lol, non je ne m'en fous pas mais je le trouve bien naif et vous n'ecoutez pas; cela fait 22 ans que je suis dans l'informatique; a cette epoque les devs etaient interessés par la finalité de qu'ils faisaient et ne s'arretaient pas au langage/techno/outils.
Aujourd'hui c'est l'inverse; j'ai vu le changement au fil des années. La techno/outils/methode est presque considérée comme une fin en soi; ou l'on se retrouve face a des gens pleins de dogmes et d'ideologies. Combien de fois on a entendu des discours de cours de maternelles (java vs c#, oracle vs sqlServer etc.) sans aucun interet.

Si vraiment c'est ça alors je dois confirmer qu'effectivement je suis de la vieille école. J'essaie de me mettre dans la peau de l'utilisateur, j'ai appris des méthodes qui m'aident à poser les bonnes questions pour ça. En dehors du développement agile il y a un tunnel sans beaucoup de communication, et à la fin la satisfaction du client confirme que les questions posées au début étaient les bonnes.

Si ça c'est démodé alors peut-être que ça explique dans une certaine mesure mes difficultés à trouver du travail. J'ai droit à des surprises. Pendant un entretien, l'interlocuteur se dit satisfait, et il faut rappeler un mois plus tard, que j'ai passé à réviser et mettre à jour les webparts, pour apprendre que le jugement était que j'étais sur des technologies dépassées. Après ça il m'a fallu trois jours pour être au top sur les WebAPI, pourquoi pas dire tout de suite ce qu'on veut ?

[Gluups]

On leur faisait passer des tests techniques avec nos experts des differentes technos et on avait une idée de leur niveau/motivation. Avec le temps on s'est rendu compte qu'il valait mieux se mefier des gens qui touchent un peu trop a tout car c'est source non pas de curiosité mais plutot d'eparpillement.

Là où une expérience composite, éclectique, peut avoir du bon, c'est quand on a besoin de quelqu'un d'adaptable. Ça n'empêche pas de suivre la culture de l'entreprise.

[kilroyFR]

Sur le marché actuel on a une plethore de jeunes gens qui cherchent a se faire embaucher dans les incubateurs a startup mais pas tant pour realiser que pour faire un hold up au salaire. Generalement ces startup du fait de lever de fonds importants disposent de moyens financiers attirant tres facilement les jeunes diplomés.
Generalement ils ne restent pas et ne produisent pas grand chose mais s'en servent pour ajouter des lignes au CV, quelques termes sur les technos et autres mots ala mode et ca suffit pour reactualiser son CV pour chercher ailleurs et faire reevaluer le salaire. Pour une startup qui sortira quelque chose il y en a 9 qui se cassent la gueule.
Au final les SSII du coin galerent comme des folles a trouver des jeunes aux salaires proposés (impossible de lutter et beaucoup de promesses, cadre de travail, esprit startup etc). Souvent on retrouve ces memes personnes en entretien dans ma boite et c'est souvent là qu'en creusant l'entretien, l'on se rend compte que ces gens ne produisent rien, mais etaient dans une equipe. L'entretien technique (quand on a depassé la terminologie) montre vite les limites et le manque cruel d'experience.
On en a eu un recemment, 2 startups en 3 ans, une liste de technos longue comme le bras. En pratique, incapable de nous decrire CONCRETEMENT ce que lui avait fait.
Ca en serait presque amusant mais je trouve ca plutot dramatique. Une certaine realité de l'emploi dans l'informatique et une tournure qui ne prend pas un bon chemin.

[Gluups]

En gros, ça se passe un peu comme en politique ?

[Marco46]

Totalement d'accord avec toi la dessus; enfin quelqu'un de pragmatique et non pas dogmatique comme c'est souvent le cas maintenant.
Les tests unitaires ca rassure les devs mais ca ne teste que les choses les plus simples - souvent ceux pour lesquels il n'y a pas beaucoup d'intelligence dans le code.

Normalement on fait exactement l'inverse, on a besoin de TU (au sens strict, c'est à dire totalement isolé de l'extérieur de la fonction à tester) lorsque c'est compliqué et qu'il y a beaucoup de cas. Sinon on prend l'approche de Ian Cooper où les TU doivent servir à découvrir l'implémentation sur la base de prérequis fonctionnels, en supposant que l'application est suffisamment bien structurée pour garder les IO à l'extérieur du périmètre à tester (clean architecture, hexagonal architecture, etc ...).

Les use case complets pour realiser des tests d'integration/fonctionnels sont pour moi ce qu'il y a de plus essentiels (et ce n'est pas une perte de temps).

Un test d'intégration sert à vérifier les cas passants entre deux systèmes, globalement un cas passant et un cas d'erreur. C'est à dire un back et un front, deux webservices l'un avec l'autre, un back et une base de données, etc ...On ne teste pas le fonctionnel avec de tels tests ils sont beaucoup trop chers à exécuter.

La logique fonctionnelle doit être testée exclusivement en unitaire, c'est à dire en mockant les I/O (pas forcément les collaborateurs internes à la logique) parce que c'est extrêmement rapide à exécuter.

Je subodore que ce que tu appelles test fonctionnel est en réalité test end-to-end dont le rôle est de traverser toute la stack avec des cas passants et en aucun cas de tester tous les corners cases complexes du métier.

Sur ce je voudrais rebondir sur ce commentaire :

Après, je vous rejoins sur l'inutilité d'un bac+5 pour faire du dev. La plupart du temps un bac +3 suffirait largement et genererait moins de frustration.

Je ne vois pas du tout en quoi 2 ans d'études en plus ou en moins changerait quoi que ce soit sur la frustration. Le problème c'est qu'on est tous contraints de travailler constamment avec une majorité de débutants pour qui toutes ces notions sont une découverte (et je parle pas du management qui est par essence incompétent sur ces sujets et qui croit pertinent de venir y mettre son nez). J'ai moi-même beaucoup de mal à appliquer et faire appliquer tous les principes que j'évoque en mission tant le niveau est faible. Mais c'est normal, il ne faut pas oublier que nous sommes dans une industrie extrêmement jeune, et IMHO la frustration vient surtout de là.

[vertex.3F]

Pour moi la principale cause est la course au moins cher / au plus rapide, sinon c'est le concurrent qui choppe le projet.

Alors pour rentrer dans les exigences clientes, dans les bons chiffres qui vont bien lors d'une réponse à appel à projet, les commerciaux sortent des trucs de leurs chapeaux, enquillent leurs primes et ensuite les pilotes / techs se débrouillent avec ce qu'ils ont.

Du coup on met moins de bonhommes, et on en met des pas chers, on limite fortement la préparation au projet et donc son pilotage dans l'ensemble et puis il n'y a plus qu'à presser les devs comme des citrons avec objectif "le bouton il faut qu'il marche". Et si ça foire, c'est à cause d'eux.

Par ailleurs il y a encore beaucoup trop cette mentalité "le client est roi" qui fait qu'on lui laisse trop de pouvoir dans le pilotage (alors que l'on est sensé lui vendre ça aussi, ainsi que l'accompagnement et de la conduite du changement).

.../...

L'agilité c'est bien mais peu comprennent ses rouages et très très peu y sont formés, c'est souvent pour faire effet de mode c'est tout mais dans le fond les roadmaps sur des années sont bien là, et à respecter car déjà vendues. Ça arrange bien les "chefs", on a posé le déterminisme du cycle en V sans se casser la tête à écrire ces specs barbantes.

Mais du coup c'est pire, les devs doivent avancer à l'aveugle, bouton après bouton, et au moindre sujet de fond qui tombe, ça fait parfois mal, souvent trop mal, et flop ! En général les gens se barrent, et puis on reprend les mêmes "chefs", les mêmes commerciaux, et on revend des trucs, on trouve d'autres petits jeunes et on recommence.

.../...

je suis bien d'accord avec ce que tu ecris, meme constat sur les projets pour lesquels j'ai bossé;

pire, l'agilité, parfois couplée au lean, ne sert qu'a davantage presser le citron des développeurs dont on ne comprend pas le boulot et sa complexité croissante (inflation du nb de briques, d'outils, méthodos, etc.);

je vois certains décideurs méfiants croire que les developpeurs sont lents ou se ménagent, et, pire, des scrum masters incapables de protéger le cadre de travail de leur equipe;

le développement nécessite souvent des connaissances larges, du savoir faire, et des temps de * concentration intense *; y'a pas de secret, le logiciel ça coute cher.

autres elements auxquels je pense :
le développeur est tout en bas de la chaine, il ne peut faire aucune impasse, ce qu'il réalise doit fonctionner coute que coute, il passe parfois des heures les soirs a chercher la solution d'un probleme technique bloquant (compil par exemple) qui est lié à l'instabilité de son environnement/de sa stack (pendant ce temps le chef de projet ou l'analyste fonctionnel ont quitté le boulot et boivent une bonne biere, tranquillement);
pris a la gorge par les délais et les charges invraisemblables, il peut lui arriver régulièrement de devoir compenser des "trous" laissés par les contributeurs du projet en amont (a tous les niveaux : commerce, architecture, spécification métier, spécif fonctionnelle, ...); sa charge de travail est fréquemment sous estimée (optimisme généralisé et incompétence de l'organisation à identifier les risques par exemple);

[vertex.3F]

lol, non je ne m'en fous pas mais je le trouve bien naif et vous n'ecoutez pas; cela fait 22 ans que je suis dans l'informatique; a cette epoque les devs etaient interessés par la finalité de qu'ils faisaient et ne s'arretaient pas au langage/techno/outils.
Aujourd'hui c'est l'inverse; j'ai vu le changement au fil des années. La techno/outils/methode est presque considérée comme une fin en soi; ou l'on se retrouve face a des gens pleins de dogmes et d'ideologies. Combien de fois on a entendu des discours de cours de maternelles (java vs c#, oracle vs sqlServer etc.) sans aucun interet.

si vous exerciez il y a 22 ans, souvenez-vous des technos de l'epoque;
comparé à aujourd'hui, le panel des technos informatique etait très restreint, de facto les developpeurs etaient plutot "canalisés" sur ce plan je pense;
il me semble aussi que les profils des développeurs etaient moins "techniques", et davantage orientés "métier";
du coup, mécaniquement, les discours de maternelles (comme vous les nommez) portaient sur d'autres sujets...

Et non je ne prends personne de haut

Chacun de nous fait comme il peut pour raisonner aux niveaux d'abstraction auxquels il peut accéder. Celui qui serait hautain ne doit pas oublier qu'il s'exposerait à être détesté (par exemple).

La production de logiciel est une industrie comme une autre.

Ca me fait mal (au yeux) de lire ça sur un forum spécialisé en informatique, pire (mal plus bas) venant de la part d'un architecte qui met en avant 22 années d'expérience.
L'info est mon second métier après l'industrie, ça tombe bien... et je ne suis pas seul à estimer que le premier domaine (le dév informatique) ressemble davantage à du prototypage qu'à un process industriel. Au passage j'exerce mon métier de développeur depuis 20 ans (moi aussi je peux frimer d'avoir corrigé et créé des bugs depuis si longtemps...).
J'ai trouvé un peu de lecture récente (premiers liens via recherche google) :

• Pourquoi l’industrialisation informatique ne marche pas (1ière partie) : https://fr.linkedin.com/pulse/analys...pas-poudevigne
• Pourquoi l’industrialisation informatique ne marche pas (deuxième partie) : https://www.linkedin.com/pulse/analy...s-poudevigne-1

[sebastiano]

Au final les SSII du coin galerent comme des folles a trouver des jeunes aux salaires proposés (impossible de lutter et beaucoup de promesses, cadre de travail, esprit startup etc)

Les SSII galèrent ? Elles n'ont qu'à revoir leurs marges, qui sont tout simplement énormes.

[kilroyFR]

Ca me fait mal (au yeux) de lire ça sur un forum spécialisé en informatique, pire (mal plus bas) venant de la part d'un architecte qui met en avant 22 années d'expérience.

C'est un simple constat de l'evolution de metier.
Quelque chose qu'on peut automatiser assez facilement avec les methodes/modeles/outils de developpement actuels; voire sous traiter a des "ouvriers", que vous le vouliez ou non.
J'ai evolué avec mon epoque; je ne chercher plus a lutter ou essayer de me persuader qu'on fait un metier a part des autres.
On est passé de l'artisanat a l'industrialisation dans le dev en quelques decennies.
Si l'industrialisation ne marche pas chez vous c'est que vous etes encore a l'etat de l'artisanat et n'avez pas embrassé tous les concepts et autres paradigmes novateurs de notre epoque. Vous connaissez les archis micro services ? SOA ? vous devriez vous y interesser car couplée a DevOps elles pemettent une industrialisation des dev et deploiements qui marche de maniere redoutable. De plus en plus d'entreprises y passent et a juste titre.
Pas besoin de chercher un article sur le net pour essayer de se rassurer en trouvant les excuses pour se persuader que ca ne fonctionne pas (un peu comme ceux decriants les dev off-shore). Car moi je le vis depuis 6 ans, ca fonctionne parfaitement bien quand tout le monde va dans la meme direction (oui avec du dev off-shore). C'est du gagnant gagnant pour tout le monde.
Par certains aspects les articles en liens font sourire car deja obsoletes dans leur maniere d'organiser les devs (offshore).

[vertex.3F]

.
Pas besoin de chercher un article sur le net pour essayer de se rassurer en trouvant les excuses pour se persuader que ca ne fonctionne pas (un peu comme ceux decriants les dev off-shore).

Notre discussion découle d'une actualité qui s'intitule "Étude : 50 % des projets de développement d'applications se soldent par un échec".
Le chroniqueur pose 3 questions (que je trouve opportunes) :

• Que pensez-vous des résultats de l'étude ?
• Quels sont selon vous les facteurs d'échec les plus importants d'un projet IT ?
• En tant que développeur, gérer la dette technique fait-il partie de votre quotidien ? Combien de temps y accordez-vous en moyenne dans la semaine ?

Perso je n'ai pas besoin de me rassurer : autour de moi les projets ne sont pas épargnés miraculeusement.
Ce qui accrédite l'article.

Vouloir imposer le dogme qui consiste à penser que l'informatique pourrait être industrialisée contribue à ces échecs sans aucun doute pour moi.
Avec l’essor de l'agilité, imaginer que la production de logiciel est industrielle me parait dépassé, aujourd'hui on enseigne aux élèves des filières informatiques les différences entre des notions comme le projet (unique), les processus (répétitifs, qui peuvent accompagner les étapes d'un projet), la méthodologie, l'outillage, etc.
Il n'y a pas de projet identique à un précédent (un projet informatique est unique lui-aussi). Par contre il peut exister 2 logiciels identiques, le second facilement obtenu par copie du premier (c'est le début d'une production industrielle).

Bref... je suis tenté de dire que bien des articles sur "le net" pourront exprimer ces concepts mieux que moi (afin de s'affranchir du dogme ... si on peut).

[Grogro]

Je ne vois pas du tout en quoi 2 ans d'études en plus ou en moins changerait quoi que ce soit sur la frustration. Le problème c'est qu'on est tous contraints de travailler constamment avec une majorité de débutants pour qui toutes ces notions sont une découverte (et je parle pas du management qui est par essence incompétent sur ces sujets et qui croit pertinent de venir y mettre son nez). J'ai moi-même beaucoup de mal à appliquer et faire appliquer tous les principes que j'évoque en mission tant le niveau est faible. Mais c'est normal, il ne faut pas oublier que nous sommes dans une industrie extrêmement jeune, et IMHO la frustration vient surtout de là.

En un sens si, puisqu'on fait un bac+5 pour faire un travail d'ingénieur (qu'on ait le titre ou non, une énième aberration franco-française sur laquelle on ne va pas revenir), avec une paye d'ingénieur, pas pour faire un boulot de technicien, simple exécutant à qui il est interdit la moindre initiative, même si cela lui sera reproché en entretien annuel ensuite pour prétexter le gel du salaire pendant N années, avec une paye inférieure à un technicien. Les métiers de l'informatique ont quelque chose de pathologique en France.

La frustration des débutants vient aussi que 90% des projets sont de la maintenance, parfois chez le client, parfois en CDS. Sans doc, sans normes de codage, allant à l'encontre de toutes les bonnes pratiques qu'on leur a apprises à l'école, avec une architecture spaghetti, sans ORM (ou plusieurs bouts d'ORM maison qui se télescopent), et un code dégueulasse qui relève d'une sédimentation de micro-décisions aberrantes sur des années. Parce que des dizaines de presta s'y sont succédé au fil des ans. Et sur des technos ancestrales genre java 6 avec des bibliothèques maison qui sont des copier-coller de bouts de bibliothèques standard, mais qu'il est interdit d'utiliser pour des raisons X ou Y (qui ont pu avoir une légitimité à une époque mais qui semblent arbitraires). Avec genre du Struts pour le front. Ou devbooster (ceux qui ont bossé pour le crédit mutuel comprendront). Mais ce code marche, et le refondre ça prend énormément du temps, et c'est un gros risque.

Pour en rajouter à la frustration, pas mal de jeunes diplômés ont pu faire leur alternance dans une vraie entreprise avec de vrais projets. Quand on se retrouve ensuite à faire de la merde indigente en SSII parce que c'est 90% du marché de l'emploi, pour une paye indigente, ça file une énorme claque. Et j'en ai vu pas mal devenir cyniques ou désabusés en quelques mois. Ou devenir simplement mauvais, sans aucune rigueur, alors qu'ils semblaient prometteurs avec de bonnes capacités. Ce qui génère aussi beaucoup de frustrations côté client puisque ces ressources leur ont été vendues comme "experts" par le commercial du viandard. Or ces SSII embauchent à 80% des débutants (jeunes diplômés ou moins de 2 ans d'expérience). Et si le commercial est honnête, c'est la SSII concurrente qui décroche le contrat. Un gros contrat perdu ça fait parfois TRES mal (cf les mésaventures de Sopra Steria Banking la semaine dernière).

Quand on fait de la presta en SSII, on bosse souvent sur des grands comptes. Ce sont des projets intéressants quand on sort de la technique pour appréhender le métier, mais qui sont abrutissants au possible pour un développeur, qu'il soit bon ou mauvais (et s'il est bon, en quelques mois il deviendra au mieux moyen tellement il sera sous utilisé). Et les débutants découvrent toutes les rigidités de l'entreprise française ultra verticalisée, son management franco-français catastrophique, la culture du présentéisme, ses silos métiers étanches, où la moindre demande d'information qui doit passer par le N+2, puis par le chef de service rival du N+2, dont les dents rayent le parquet pour se faire bien voir du N+3 et du N+4. Découvrent empiriquement le principe de Peter voire de Dilbert, les délires de la cellule marketing sous coke (). Les spécifications fantaisistes, lacunaires, ou contradictoires, qu'on leur demande d'appliquer au pied de la lettre le plus rapidement possible.

Il y a aussi un gros malentendu dès l'école puisque le développement n'est qu'une composante de notre métier. Notre métier, c'est la prestation de services pour le tertiaire. Nous sommes en quelque sorte tous des consultants low cost, et le développement n'est qu'un outil à mettre au service du métier et de l'utilisateur final. Beaucoup de dev ne le comprennent jamais. De mon point de vue, c'est pourtant l'articulation entre le métier et la solution logicielle qui constitue la partie la plus intéressante du métier. C'est pour ça que sont faites les architectures micro-services.

On est je crois le seul pays au monde où le SI n'est pas considérée comme un métier de l'entreprise mais comme un coût et une charge à externaliser le plus possible. On a une culture d'entreprise maladive jusqu'à l'os en France.

[pmithrandir]

Kilroy, ce que tu nomme industrialisation existait deja quand j'etais etudiant en 2001. Et c'est meme ma base des projet en cycle en V, qui se plante dans des pourcentages encore plus élevé.

Et je te rejoins, les projets informatiques et le metier de developpeur se rapproche d'autres... sauf que les pradigme d'entrepriuse entière sont en train d'évoluer vers la fin de l'industrialisation. L'agilité gagne des entreprises entière, et justement ca se retrouve partout.

Le principe est assez simple, l'industrialisation permet de crééer très peu de valeur par individu, mais a grande échelle.
Elle n'est valable que sur des process récurrents et reproductible à l'infini. (autrement la phase d'analyse initiale coute trop cher)

L'artisanat est en effet moins puissant pour la production de masse, donc sur ce type de marché l'industrialisation est efficace.

En revanche, l'artisanat apporte une création de valeur bien plus importante, en particulier par l'utilisation de tous les cerveaux, et non de quelques un.

Mais nous parlons ici d'une bataille deja obscolete... l'agilité a l'échelle, les entreprises libérées / TEAL ou queque soit le nom qu'on donne a ces process partent tous dans la meme direction, peu de reflexion centralisée, une mutualisation des cerveaux et une puissance cumulée exponetielle par rapport aux organisations précédentes.



En bref, ton organisation est surement efficace dans ton domaine. Elle n'est possible que parce que vous avez du dev a bas cout.
Je n'ai nul doute que si un concurrent serieux et agile se présente vous mourrez en quelques mois.


Je vais te raconter l'histoire de l'OS génial développé par 1000 ingenieur chinois vers 2005 pour téléphone. Industrialisation intensive, etc... En face de cela, Apple a mis une équipe de 25 30 personnes pour crééer un petit OS pour smartphone.

Ais je besoin de te dire qui a gagner la course ?

[el_slapper]

(.../...) Notre métier, c'est la prestation de services pour le tertiaire. Nous sommes en quelque sorte tous des consultants low cost, et le développement n'est qu'un outil à mettre au service du métier et de l'utilisateur final. Beaucoup de dev ne le comprennent jamais. De mon point de vue, c'est pourtant l'articulation entre le métier et la solution logicielle qui constitue la partie la plus intéressante du métier.

Dans mes bras!!! Faire de la technique, tout le monde peut le faire, et une fois que c'est fait, ça n'est plus à faire. Par contre, faire face à un besoin client sans cesse innovant, et l'accompagner, ça c'est rigolo.

On est je crois le seul pays au monde où le SI n'est pas considérée comme un métier de l'entreprise mais comme un coût et une charge à externaliser le plus possible. On a une culture d'entreprise maladive jusqu'à l'os en France.

Là aussi tu prêches un convaincu. Il y a des ilôts ou ça n'est pas vrai, mais c'est vraiment une plaie, le management à la Française. Après, j'ai connu un directeur de grande banque Française(qui traitait le président Sarkozy comme un subalterne, accessoirement...) qui n'hésitait pas à téléphoner tous les soirs à des chefs de projet qui pilotaient des projets stratégiques(vraiment stratégique, hein, pas des jouets pour occuper le boss). Mais j'en ai vu un seul. Tous les autres.....

[Marco46]

On est passé de l'artisanat a l'industrialisation dans le dev en quelques decennies.
Si l'industrialisation ne marche pas chez vous c'est que vous etes encore a l'etat de l'artisanat et n'avez pas embrassé tous les concepts et autres paradigmes novateurs de notre epoque. Vous connaissez les archis micro services ? SOA ? vous devriez vous y interesser car couplée a DevOps elles pemettent une industrialisation des dev et deploiements qui marche de maniere redoutable. De plus en plus d'entreprises y passent et a juste titre.

Tu confonds l'industrialisation des processus de build et de delivery, qui démarre après l'écriture du code source et le développement stricto-sensu qui est par essence de l'artisanat, c'est du fait main spécifique à chaque fois.

Donc non la production de logiciel n'est pas un processus industriel. En aucun cas. La gestion de ce qui se passe après le développement peut être industrialisée, là oui.

[Marco46]

En un sens si, puisqu'on fait un bac+5 pour faire un travail d'ingénieur (qu'on ait le titre ou non, une énième aberration franco-française sur laquelle on ne va pas revenir), avec une paye d'ingénieur, pas pour faire un boulot de technicien, simple exécutant à qui il est interdit la moindre initiative, même si cela lui sera reproché en entretien annuel ensuite pour prétexter le gel du salaire pendant N années, avec une paye inférieure à un technicien. Les métiers de l'informatique ont quelque chose de pathologique en France.

Un développeur ne peut pas être un simple exécutant, peu importe son niveau d'étude. Après que des gens dans le personnel de management pensent qu'un développeur a le même rôle qu'un ouvrier dans une chaîne de montage c'est un autre problème lié à l'incompétence du management en général.

En d'autres termes, il n'y a pas de travail dans le développement qui corresponde à celui d'un simple exécutant technique qui suit des instructions servilement, ça n'existe pas. Malheureusement, le problème c'est que des gens qui sont souvent à des postes de pouvoir et de décisions pensent que ça existe.

Il y a aussi un gros malentendu dès l'école puisque le développement n'est qu'une composante de notre métier. Notre métier, c'est la prestation de services pour le tertiaire. Nous sommes en quelque sorte tous des consultants low cost, et le développement n'est qu'un outil à mettre au service du métier et de l'utilisateur final. Beaucoup de dev ne le comprennent jamais. De mon point de vue, c'est pourtant l'articulation entre le métier et la solution logicielle qui constitue la partie la plus intéressante du métier. C'est pour ça que sont faites les architectures micro-services.

Le métier du développeur c'est de transformer une expression du besoin plus ou moins bien détaillée rédigée en langage naturel en spécifications (langage formel) permettant la génération d'un programme exécuté par une machine. C'est ça notre métier. Le fait que l'on soit prestataire pour une organisation ou en interne dans une organisation ça c'est relatif au poste, pas au métier. Dans les deux cas on est au service de l'utilisateur, simplement dans le cas de la prestation on est d'abord au service de notre propre entreprise et seulement après au service de l'utilisateur. Et ça c'est pas du tout relatif au métier, c'est relatif au poste (ta place dans l'organisation générale).

[el_slapper]

C'est rigolo, votre discussion.

Toute mon expérience me pousse à être dans le camp de Marco46, et pourtant..... et pourtant, ça ne veut pas dire que KilroyFR a tort. Il vit juste dans un autre monde. Dans un monde ou on ne peut pas recruter les meilleurs, parceque Google et les autres les ont tous ratissé. Dans un monde ou les seuls développeurs qu'on trouve n'ont ni la motivation ni le talent pour bosser comme un développeur devrait. Et qu'on doit donc encadrer comme des tacherons. Parceque c'est le seul moyen d'en tirer quand même un petit quelque chose.

Son expérience n'est pas la notre, mais elle est tout aussi réelle. Son monde existe autant que le notre. Ses solutions correspondent à une vraie situation, un vrai besoin, de vraies contraintes. Elles sont très inefficaces comparées aux nôtres, mais ses contraintes lui interdisent d'utiliser les nôtres.