Discussion :

[Tr0n33]

C'est pour ca que la reconversion est si difficile. Les recruteurs considèrent aussi qu'un jeune est maléable, et peut être formé, mais que ca n'est plus possible après quelques années (ce qui est bien sur idiot, mais c'est comme ca...)
Ajoutez à ca les contraintes RH : les grilles de salaires dépendent de l'âge, et payer un profil "junior sur ce poste" plus cher parceque la personne est plus agée, beaucoup ne voudront pas, puisqu'ils ont pléthore de jeunes

C'est pour cela que je conseillais effectivement des petites entreprises qui ont généralement plus de malléabilités dans les critères de recrutement et qui se fondent beaucoup sur le relationnel des individus. Je suis totalement d'accord avec vous sinon et c'est bien malheureux. J'essaie chez les clients aussi bien que les grandes entreprises pour lesquelles je travaille, de faire passer cette idée : le risque est gagnant surtout avec les lois relativement libérales actuelles (notamment au vue des durées des périodes d'essai qui sont colossales pour les cadres, de plus en plus fixées dans les conventions à 2 x 6 mois pour les SSI). On a toujours besoin d'un profil atypique pour la fraîcheur qu'il peut apporter dans le monde de l'informatique. Et pour avoir pris le paris 5 ou 6 fois avec ma petite entreprise, nous avons toujours eu un retour ultra positif (il suffit de savoir les mettre en valeur et les positionner sur des postes adaptées). Personnellement, nos clients veulent juste de la compétence, de l'adaptabilité et un bon relationnel avant tout. Le décalage entre les achats/RH et les équipes sur place (en fonction des besoins de poste) est d'ailleurs un gouffre qui pose beaucoup de soucis. La réalité du métier n'est pas la réalité des ressources humaines. J'ai souvent vu d'ailleurs les grosses boîtes qui ne prennent pas de risques sur les profils, appelez ma petite boîte car elles avaient besoin d'un profil atypique (il y a donc toujours un créneau à prendre, qu'il faut trouver - j'avoue c'est compliqué).

En fait, j'ai l'impression que c'est une belle arnaque et une belle illusion. Quand j'ai eu ma formation RH sur les traitements de certains profils, j'ai constaté que les meilleurs profils dans mon métier était toujours ceux qui étaient atypiques. Ils avaient toujours un je ne sais quoi qui apportait une plus valus sur les dizaines de CV que je recevais. Notre petite société est là pour gagner de l'argent et avoir un "savoir faire" qui pourrait la placer au dessus des autres. L'humain, la communication, le métier sont des valeurs par exemple que nous avons mis dans nos engagements plutôt que l'expertise et la technique. C'est une forme de profils qui est techniquement moins bon qu'un expert, mais qui est cent fois plus communiquant et motivé. La seule barrière comme je l'évoquais : les achats. Sinon en 10 ans, nous avons eu 95% de réussite sur entretien malgré parfois une concurrence rude.

Je partage votre analyse, mais j'ai envie d'être un peu plus optimiste

[Invité]

"2- Considérez l'échec comme un mur infranchissable qui est un boulet à traîner plutôt qu'un apport d’expérience."

Ca fait un peu défaitiste dit comme ça...

[Tr0n33]

"2- Considérez l'échec comme un mur infranchissable qui est un boulet à traîner plutôt qu'un apport d’expérience."

Ca fait un peu défaitiste dit comme ça...

Oui je sais, c'est triste. Ce n'est pas ma vision là, mais une forme de pragmatisme sur la réalité du monde du travail en France. Mentalité à changer sur le sujet. Prions !

C'est souvent ça, mais dans ce cas précis, c'était plus subtil. Pour garder le contrôle de leur "architecture", les grands pontes avaient exigé un contrôle total sur les livraisons des composants par des équipes dédiées. Même en intégration. Les devs JAVA n'avaient même pas le droit de créer leurs propres classes, ils devaient passer par une bureaucratie profonde. Nous, en COBOL, on pouvait créer un composant comme on voulait, et le livrer en prod en 4 minutes chrono. Le seul point sur lequel il y avait un contrôle, c'étaient les scripts(on appelle ça les JCL) des chaines. Si la chaine machine devait partir à 18h00, mais seulement à bonne fin de la chaine truc, et en présence du fichier bidule, alors si le fichier bidule changeait de nom, il fallait faire une demande, qui pouvait durer jusqu'à trois semaine. En vrai, elle durait deux jours. Les gens du JAVA, eux, avaient des installations en intégration qui duraient une semaine. . Pauvres malheureux. Ils ne pouvaient pas lutter. On avait des flingues, ils avaient des cailloux.

Je connais bien ces problématiques, j'ai déjà eu l'occasion de compiler et modifier des JCL en mode pompier (bien que je ne sois pas du tout développeur COBOL et que ce ne soit pas mon truc). Les processus d'intégration, c'est l'artillerie lourde du monde Java (je prends un raccourci). C'est très bien mais parfois inutile pour de l'automatisation de traitements simples. Avec mes dernières expériences, j'ai pu développer du Spring Batch. D'ailleurs chez le client où j'étais, ils migraient progressivement leurs programmes COBOL vers du Spring batch qui appelle des Webservices SOAP (puis REST avant que je parte) en Java. Nous avions fait des comparatifs des coûts d'évolution des programmes COBOL (par exemple pour intégrer des processus d'envoi de SMS automatique en parallèle des traitements batch). J'aurais plutôt dit que vous aviez des flingues et qu'ils avaient des destroyers interstellaires pour tirer sur des Wookies. Forcément, s'il faut faire des demandes en trois exemples pour avoir la possibilité d'ouvrir une chaine internet pour lancer un webservice spécifique (alors qu'il en faut 10 pour faire tourner le bousin...), c'est long, chiant et lourd.

Ca dépend du besoin

J'aurais adoré voir ça. Mais je ne crois pas que ça aurait marché dans le contexte de l'histoire que je raconte. Parceque le développement et la maintenance, ce n'est pas le même budget.

C'est conquis de haute lutte et surtout grâce à une entité interne à l'administration chargé de réfléchir sur les nouvelles méthodes de travail. Ils faisaient des ateliers pour présenter toutes les nouveautés. Ca a permis à l'essentiel de la hiérarchie d'y assister et de voir les modes de fonctionnement. Dans une administration réactionnaire, c'était pas gagné et pourtant, face à la réalité, en utilisant des lego, l'équipe leur a appris ce qu'était Scrum (veridict pour les legos). De même ils ont introduit la programmation orienté aspect (avec Spring Aop) pour ouvrir un peu l'esprit de tout le monde et ainsi de suite. A partir du moment où un grand muffti bouge, c'est gagné. Je suis actuellement en train de mener une campagne similaire dans une autre grande société. On en est à l'étape : faire accepter le Scrum et les processus d'intégration continus (non pas pour du développement d'ailleurs). Nous sommes en guerre ouverte contre les coutumes hiérarchiques ancestrales. Franchement, je pense que c'est possible de le faire passer dans toutes les boîtes; question d'investissement. C'est d'ailleurs la même erreur que font les RH. Ils appliquent des principes de profils qui manquent cruellement d'évolution, et de réalité sur les individus et le travail d'informaticien de nos jours.

Sinon si si. La différence entre mentir à un chef pour qu'il soit content et faire du travail dans son dos en douce, elle est mince d'un point de vue moral. J'avoue, j'avais abusé. Mais bon, j'en avais vraiment marre de passer 4 h à déployer à chaque mise en production parce qu'il y avait 4 threads de disponible pour un SI qui déployait 500 modules (et quand un thread est bloqué pendant 2 h, merci la file d'attente). J'ai craqué, on a fait développer une interface bien meilleur pour gérer la gestion de conf, la fabrication et le déploiement (impossible de faire passer en douce un projet à 200 jours hommes ^^).

[garn]

Ca me rappelle ma 1ere expérience en chef de projet. Contexte : regie dans une équipe de 4 personnes de la même SSII (dont moi)
Il nous faut une ressource de plus pour combler un départ. Boulot d'AMOA (comprendre un contexte métier, tests fonctionnels...) sur un contexte ETL (comprendre un ETL, SQL...)

On m'a filé un jeune, BAC+5 sortie d'école, alternance faite dans la SSII, en periode d'essai dans son CDI suite alternance. Le type avait déja fait ami ami avec le directeur du département, déja touché a plein d'ETL
Il a RIEN foutu en 3 mois de mission; il nous a meme donné plus de boulot en faisant des erreurs qu'il n'a réussi a en corriger. Il avait demandé à la boite à faire de l'AMOA pour tester, ca lui a pas plu, il a abandonné le projet. En restant au meme poste bien sur. Il était en période d'essai mais ayant copiné avec la hierarchie de la SSII il se savait en sécurité, parfois moins de 3h de boulot par jour il disparaissait, refusait de rendre des comptes...Je l'aurais tué
j'ai remonté les problemes, ca a pris près de 3 mois pour le sortir proprement, entre temps l'équipe a du combler sa part du boulot. Le type avait eu le culot de se plaindre que c'était emmerdant comme travail
A noter que le travail "emmerdant" est la plus grosse expérience de ma carrière pour l'instant, refonte complète de SI d'un gros gros client, mais bref.

A la place le commercial de la SSII, me file un senior, avec en commentaire "celui la tu pourras lui filer n'importe quoi en travail il t'emmerdera pas", consultant +40 ans qui cherchait un travail en interne, ne pouvait pas partir de la SSII car famille à gérer, malgré le fait qu'on lui filait de la merde en mission. Un pur technique dont le profil correspondait pas à de l'AMOA, mais j'ai pas eu le choix. Le gars s'est révélé devenir notre meilleure recrue : il a eu un peu plus de mal à comprendre le fonctionnel, respecter les procédures, mais sur ce qu'il connaissait il a pris l'initiative de refaire des macros pour automatiser. Il a juste fallu le former, etre derrière lui pendant un temps, mais à coté de ca, esprit d'initiative, bonne analyse, aucun problème a être formé sur quelque chose de contraire à son métier de développeur

A la base je sais très bien que la SSII m'avait donné ce type de profil pour m'emmerder parceque j'avais fait sortir leur super junior

N’empêche que j'ai jamais autant ressenti la différence entre le jeune imbu de lui même qui en début de carrière se permet de ne pas travailler, et un sénior qui en a vu de toutes les couleurs, connait la difficulté de la vie, et a tiré de cette expérience autant de chose qu'on a pu apprendre de lui

[Tr0n33]

Entièrement d'accord.

Mais il y a une autre réalité, malheureuse souvent : de jeunes cons font souvent de vieux cons et restent d'un certain point de vue, des profils Junior à mon sens malgré 20 ans d'expérience. J'ai croisé récemment une personne de 45 ans qui avait les mêmes soucis que ton jeune imbu de lui même. Je n'ai jamais compris comment il avait réussi à passer entre les mailles du filet des RH (peut être aussi grâce à du copinage). Ces profils là sont "Junior" à mon sens. J'ai toujours eu du mal à traiter ces problématiques humaines car il est difficile de savoir à qui tu as réellement à faire en le voyant 3 h par jour

[el_slapper]

(.../...)Le décalage entre les achats/RH et les équipes sur place (en fonction des besoins de poste) est d'ailleurs un gouffre qui pose beaucoup de soucis. La réalité du métier n'est pas la réalité des ressources humaines. (.../...)

Tout est dit. Tant les RH que les achats ont des excuses, d'ailleurs :

(RH) : on doit recruter pour une carrière complète, pas pour un seul poste.
(Achats) : on doit réduire les couts.

Mais ces excuses sont pourraves. Refuser de recruter quelqu'un(pas moi) que le DSI(d'un groupe de 3000 personnes) a qualifié de "10 à 20 fois plus productif que les autres prestataires", ou refuser(au même endroit) un presta à 600(pas moi, hélas...) qui ferait en un mois ce que le prestataire à 400 ne saurait pas faire en trois mois, c'est comme virer Franck Ribéry du centre de formation de Lille parce qu'il a de mauvais résultats scolaires(comme si ça en faisait un mauvais footballeur) - toutes proportions gardées.

C'est une question de pouvoir, je crois. Donner un pouvoir de décision aux équipes, c'est leur laisser bien trop d'importance dans les délicats jeux de pouvoir. Pire, laisser des gens "hors-norme" en prestataire, ou pire, en interne, c'est laisser le loup dans la bergerie. Par définition, ces gens-là sont plus difficiles à "gérer"(lire à manipuler par les méthodes standard de marketing). Le calcul qui est fait, c'est que des gens moins compétents, mais qui répondent de manière standard aux carottes standard(si tu fais des heures sup, on dira du bien de toi à ton commercial/aux RH), au final, sont plus rentables, parce qu'il font ce qu'on leur demande, et qu'ils ne prennent pas de décision surprenante qui risquerait de mettre en péril le planning.

Je prétends que ce calcul est faux. L'incompétence met en péril le planning bien plus qu'un connard(moi) qui décide de rajouter une activité non spécifiée de 5 jours - mais qui par sa connaissance du terrain sait que ces 5 jours vont en faire gagner 3 chaque mois. Mais ce qui rend ce calcul faux, c'est l'incapacité organique de la hiérarchie à saisir l'ensemble des activités de la base. Je dis "organique", parce que notre activité est très peu planifiable précisément, et que des tâches dont la valeur ajoutée n'est pas vendable auprès la hiérarchie sont pourtant essentielles. C'est la règle des 3C : la confiance sans contrôle c'est de la connerie - mais le contrôle sans confiance, c'est aussi de la connerie. Et le contrôle doit être macro : l'appli doit tourner(ou le projet doit avancer, et ça doit être mesurable). Mais aller contrôler que la tâche planifiée pour 3 heures n'en a pas pris 4, c'est une méconnaissance totale des contraintes de notre métier(et j'ose imaginer que d'autres métiers souffrent pareillement). Ce qui sauve nos projets, 90% du temps, c'est quelqu'un qui dit "j'ai fait fausse route, en fait, il faut faire autrement". Et ça, ça demande du talent, pas de la conformité.

Mais vu que notre métier est jeune(et donc pas grand monde ne le comprend), et que nos décideurs ne l'ont jamais pratiqué, et appliquent des grilles de lecture erronées(notamment un WBS à l'heure près de chaque sous-tâche), on va encore souffrir pas mal, j'en ai peur.

[Tr0n33]

Tout est dit et on en revient à ce que nous disions au début : problème pur de gestion de près carré des hiérarchies.

L'analogie du sport est assez amusante. Mon vieux père travaille dans le sport de haut niveau et oui, c'est exactement pareil, les guerres internes entre les sportifs, les fédérations et les ligues résument très bien les luttes. Tu pourrais rajouter les luttes entre les équipes mêmes au niveau conception, architecture et choix techniques. En Histoire (et non en économie), Marx affirmait que dans tous les cas une couche indéboulonnable hiérarchique et bureaucratique se mettaient en place pour les luttes de pouvoir. L'informatique n'échappe pas à la règle. Raison pour laquelle je milite aussi bien pour arrêter de penser de manière individuelle que de manière largement collective. Il faut essayer de nuancer, d'un certain point de vue, et penser l'individu à l'intérieur d'un collectif. Ce qui est dur à accepter c'est de voir une lutte de pouvoir individualiste, qui ne profite pas réellement à la hiérarchie alors qu'elle aurait bien plus à gagner en changeant ses méthodes (mais c'est la même chose pour une organisation syndicale qui cherche à imposer un élément collectif sans prendre en considération les besoins réels des individus).

[kEep OnE]

Nein. Je suis plutôt dans la catégorie érudit mais nous ne dénigrons, j'ose espérer, jamais un bidouilleur. Lors de la dernière mission par exemple, nous avions toute une partie de design web : maquettage, javascript etc. Généralement ça bidouille en CSS, ça passe des heures à essayer de faire un cadre compatible sur IE6 et Firefox, puis ça s'arrache les cheveux parce que ça ne marche jamais. Ce métier là, je suis tombé sur un véritable petit génie : aucune formation informatique, juste une connaissance de la bidouille. Il nous a fait le truc aux petits oignons en un temps record (et vu que les érudits détestent cette partie...). Comme il a été évoqué plus haut, il faut de tout pour faire une équipe viable : un bidouilleur, un junior débutant, un expert senior, peut être un senior en formation, peut être un junior génie de la technique. Bref. C'est tout un ensemble avec les spécialités de chacun qui permet d'avoir quelque chose de "construit". D'où la réponse : l'expérience est un gros plus, mais ne justifie en rien le type de profil. Ce n'est qu'un indicateur parmi d'autres.
.

Merci, ça me rassure un peu. J'ai déjà été testé aussi un peu par un dev français qui faisait du recrutement qui disait que 90% des candidats dev web n'avaient que peu de connaissances générales et que j'en avait bien plus (et aussi que je suis payé au lance-pierre au Japon lol). Le problème c'est que je peux par contre bloquer un peu plus sur des trucs pointus. Ce qui m'inquiète le plus c'est que je n'arrive pas à me spécialiser. Enfin bref, on verra bien comment je poursuivrai ma carrière.

[Tr0n33]

Merci, ça me rassure un peu. J'ai déjà été testé aussi un peu par un dev français qui faisait du recrutement qui disait que 90% des candidats dev web n'avaient que peu de connaissances générales et que j'en avait bien plus (et aussi que je suis payé au lance-pierre au Japon lol). Le problème c'est que je peux par contre bloquer un peu plus sur des trucs pointus. Ce qui m'inquiète le plus c'est que je n'arrive pas à me spécialiser. Enfin bref, on verra bien comment je poursuivrai ma carrière.

Je vous fais une petite réponse en privée.


Je continue de creuser le sujet d'ailleurs. Le noeud du problème, la confusion entre l'expertise et l'expérience. Je suis donc allé aux aurores regardées la norme NF X 50-110 issus de l'article sur l'expertise de wikipedia : évaluer une question posée, élaborer une méthode de résolution de la question posée, réaliser un certain nombre d'actions, analyser de façon critique les données en entrée et les actions menées, fournir le produit de l'expertise, gérer les aléas, les incidents et les évolutions. En somme la définition (paraphrasée) proposée par l'Afnor (et directement issu du "management par la qualité" indique wikipedia). L'expérience, quant à elle, est l'élaboration d'un savoir fondés sur la réflexion, l'intuition aussi bien que le vécu analysé de manière subjective de l'individu. Donc d'un certain point de vue l'expérience englobe l'expertise mais le côté subjectif ne peut donc pas être la seule orientation à prendre en compte pour la constitution d'un profil. L'objectif d'une expertise reste de fournir une réponse à un problème. L'expérience, pour moi, ne justifie en rien l'expertise nécessaire au titre d'un profil : Junior ou Senior. Vous pouvez avoir une personne très générique sur de nombreux sujets, qui n'a pas d'expertise et qui a un profil de Senior car il répond à plusieurs critères de compétences. En fait, la question à laquelle je réfléchis suite à ce débat est : "Un Senior est-il toujours un expert dans un domaine ?". Le mot expérience est tellement subjectif par définition qu'il est difficile de l'associer à une catégorie.

[Glutinus]

Donne ce joli laïus (ça, c'est pas ironique) a un chargé de recrutement, ou un jeune RH, et il va avoir besoin d'aspirine pour une semaine ! (ça, c'est ironique)

[Tr0n33]

En même temps c'est son boulot d'avoir mal à la tête (l'usage de macro excel, de grilles et de tableurs nuit à la santé mentale des individus).

[el_slapper]

En même temps c'est son boulot d'avoir mal à la tête (l'usage de macro excel, de grilles et de tableurs nuit à la santé mentale des individus).

tu dois avoir raison : j'étais déjà fou avant, et j'adore ça.

(non, blague à part, ce que j'aime, c'est automatiser les tâches répétitives, et EXCEL est surpuissant avec ça. Et je ne suis pas si fou que ça).

[camilleK]

très juste Jitou : en france, si tu est toujours developpeur apres 10 ans d'XP tu est considéré comme avoir raté ta vie

Bref, partant du principe que j'ai raté ma vie, l'article est assez juste. La maintenance est un centre de coût extremment cher quand un logiciel à été developpé à la-rache .

Ce qui est rigolo, c'est de voir des boites recruter uniquement des séniors pour leurs équipes (et galérer bien comme il faut), alors q'un bon junior / confirmé, coaché par un senior / expert est une equipe fonctionnant au poil !

Camille

[Glutinus]

très juste Jitou : en france, si tu est toujours developpeur apres 10 ans d'XP tu est considéré comme avoir raté ta vie

Bref, partant du principe que j'ai raté ma vie, l'article est assez juste.

Pour moi, ce que veut dire cet adage, ou plutôt ce pastiche (avec la Rolex) n'a pas le même sens : la Rolex, c'est que socialement t'es naze. Pour le développeur, c'est que tu ne trouveras pas de boulot. Sauf que si t'es en poste, tant mieux, ça te concerne pas.

Ce qui est rigolo, c'est de voir des boites recruter uniquement des séniors pour leurs équipes (et galérer bien comme il faut), alors q'un bon junior / confirmé, coaché par un senior / expert est une equipe fonctionnant au poil !

Première fois que j'entends une boite qui recrute uniquement des séniors !
Je pense que le but, c'est d'avoir une bonne équipe, que ce soit des seniors ou des juniors. L'un comme l'autre peut être composé en majorité de l'un ou de l'autre. Le but au final, c'est d'avoir "des têtes bien faites", comme le prétendent souvent les SSII alors qu'ils ne n'ont rien (ou alors une tête bien faite est une belle gueule avec un sourire à la colgate et une voix de crooner )
Si ce n'est que mon avis, vu de ma planète, une équipe "moyenne" devrait être composée au moins d'un senior qui a une bonne expérience projet et technologique, et au moins un junior qui apportera de la vivacité d'esprit et une bonne vague de motivation.

[jpoulson]

Mouais.

Il ne faut non plus dire qu'une personne a besoin de N années d'expérience pour être bon dans ce qu'il fait.

Une personne n'est pas une autre, un individu peux évoluer plus vite qu'un autre ou comporter différentes forces et faiblesses.

Raisonner en terme d'années d'expérience (en démineur dans un job de planqué?) c'est établir un genre d'équation qui a mené à la "paresse" actuelle au niveau du recrutement.

Pourquoi n'as t-on pas des test objectifs pour tout simplement dire ce dont quelqu'un est capable et de pouvoir comparer à un développer "étalon"?

C'est entièrement faisable et ne pas le faire c'est laisser la porte ouverte à la pseudoscience comme un certain Patrick Vermeren l'explique dans cette vidéo.

[goomazio]

Une personne n'est pas une autre, un individu peux évoluer plus vite qu'un autre ou comporter différentes forces et faiblesses.

Entièrement d'accord avec ça. Dans le sport ce n'est pas vraiment comparable, mais en fait c'est dans tous les domaines : on voit des prodiges de plus en plus jeunes...

[Grogro]

C'est souvent ça, mais dans ce cas précis, c'était plus subtil. Pour garder le contrôle de leur "architecture", les grands pontes avaient exigé un contrôle total sur les livraisons des composants par des équipes dédiées. Même en intégration. Les devs JAVA n'avaient même pas le droit de créer leurs propres classes, ils devaient passer par une bureaucratie profonde. Nous, en COBOL, on pouvait créer un composant comme on voulait, et le livrer en prod en 4 minutes chrono. Le seul point sur lequel il y avait un contrôle, c'étaient les scripts(on appelle ça les JCL) des chaines. Si la chaine machine devait partir à 18h00, mais seulement à bonne fin de la chaine truc, et en présence du fichier bidule, alors si le fichier bidule changeait de nom, il fallait faire une demande, qui pouvait durer jusqu'à trois semaine. En vrai, elle durait deux jours. Les gens du JAVA, eux, avaient des installations en intégration qui duraient une semaine. . Pauvres malheureux. Ils ne pouvaient pas lutter. On avait des flingues, ils avaient des cailloux.

Si je comprends bien, chez ce client (une banque ou une assurance donc), pour les développements java il fallait une semaine de bureaucratie pour faire une mise en recette ?

Je ne me plaindrai plus jamais de mon client.

[Mat.M]

Puis vient le développeur senior, un développeur qui prend conscience de ses propres échecs.

non ,non un développeur senior ne prend pas conscience de ses propres échecs et c'est valable pour tout développeur quel que soit le nombre d'années d'expérience.
L'échec ne vient pas du développeur il vient de la phase en amont du projet à savoir l'élaboration , la conceptualisation , la mise en spécification du projet.
Bref si le projet est mal foutu mal défini on peut très bien avoir de très bons développeurs et le projet finit par couler...
un développeur il fait ce qu'on lui dit de faire et si ce qu'il doit faire c'est pas d'équerre alors forcément le développeur va arriver à un mauvais résultat.

Un problème bien posé est à moitié résolu ( John Dewey )

donc si le projet est mal posé , par analogie, le projet risque de mal se terminer

Mouais.
Il ne faut non plus dire qu'une personne a besoin de N années d'expérience pour être bon dans ce qu'il fait.
Une personne n'est pas une autre, un individu peux évoluer plus vite qu'un autre ou comporter différentes forces et faiblesses.
Raisonner en terme d'années d'expérience (en démineur dans un job de planqué?) c'est établir un genre d'équation qui a mené à la "paresse" actuelle au niveau du recrutement.

d'accord mais quand on est "senior' avec des années d'expériences que l'on a participé à des projets "Titanic" ( perso c'était un projet de startup avec une box multimedia,entreprise sur les Champs Elysées à Paris, ça devait révolutionner le monde, des millions de budget et puis la boite a coulé en pure perte ) on commence, j'écris bien on commence, à être capable de conseiller les gens qui dirigent les projets d'entreprise pour ne pas recommettre les mêmes erreurs...

chose qu'un jeune diplômé tout juste sorti de formation je doute soit capable de faire..

parce que des projets et des entreprises qui coulent j'en ai vu un certain nombre...

Pourquoi n'as t-on pas des test objectifs pour tout simplement dire ce dont quelqu'un est capable et de pouvoir comparer à un développer "étalon"?

je ne pense pas qu'un développeur "étalon"existe...étant donné qu'en tant que collaborateur très pointu en technique on doit se réadapter ,réapprendre un métier sur chaque projet.
Sauf si le projet est super bien construit,middleware métier,couches métiers etc...

Entièrement d'accord.
Mais il y a une autre réalité, malheureuse souvent : de jeunes cons font souvent de vieux cons et restent d'un certain point de vue, des profils Junior à mon sens malgré 20 ans d'expérience.

ça c'est bien vrai vous voyez ce qui vous attend tous

[el_slapper]

Si je comprends bien, chez ce client (une banque ou une assurance donc), pour les développements java il fallait une semaine de bureaucratie pour faire une mise en recette ?

Je ne me plaindrai plus jamais de mon client.

Environ, oui. Il y avait aussi un environnement intérmédiaire avant la prod. Donc trois livraisons, avec à chaque fois de la paperasserie énorme. Bien sur, les dev java mettaient un maximum de choses dans leurs livraisons, histoire de ne pas devenir complètement fous. Mais pour faire face aux incidents de prod urgents, ils étaient assez démunis.

[Grogro]

Environ, oui. Il y avait aussi un environnement intérmédiaire avant la prod. Donc trois livraisons, avec à chaque fois de la paperasserie énorme. Bien sur, les dev java mettaient un maximum de choses dans leurs livraisons, histoire de ne pas devenir complètement fous. Mais pour faire face aux incidents de prod urgents, ils étaient assez démunis.

Mais comment les développeurs java faisaient leur qualification sur l'environnement de recette ? Chez nous on a un environnement de dev, un environnement de pré-prod + la prod, la mise en pré-prod est faite par le CP en une heure sans avoir à demander d'autorisation (par contre côté web services et bdd c'est plus long), et il nous est arrivé d'en faire 4 par jour à l'approche d'une mise en production.