L'humain sera toujours là bien évidemment mais je pense que le métier est voué à évoluer pour au final n'avoir qu'un rôle de contrôleur (comme dans le secteur bancaire en gros).Envoyé par dad3zero
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
L'humain sera toujours là bien évidemment mais je pense que le métier est voué à évoluer pour au final n'avoir qu'un rôle de contrôleur (comme dans le secteur bancaire en gros).
Bonjour
Même chanson , j'ai déjà eu des eu également des pieds nickelés à bac + 5 en DSI ... qui n'avaient pas fait une ligne de code depuis 10 ans. Mais cela se disaient chef DSI et tous les titres associables.
Je veux pas jeter de pavé dans la marre , certaines entreprises demandes carrément " Pourquoi vous n'avez pas un bac + 5 ? " . Limite si lors de l'entretien on vous dit pas non de suite et qu'on invite a retourner aux études ...
Effectivement j'ai entendu cela en décembre . Le métier de comptable est voué à disparaitre .
Effectivement la même chaine de TV qui prétendait que le métier de comptable devait disparaitre d'ici 2040 , disait aussi dans le reportage d'après que les français vont avoir encore plus recours aux comptables avec les nouvelles réglementations fiscales ! Cherchez l'erreur
Ce qui niveau comptable représente beaucoup d'emplois. Sans compter les lois de finance qui arrivent continuellement. Cela fait déjà belle lurette que tout est automatisé en comptabilité pour les grands compte et pour autant il y a beaucoup de personnel nécessaire (sur la partie conseil notamment).
Passer aux archis micro services c'est le moyen le plus efficace pour :
- ne plus avoir besoin d'experts pour coder (se limiter a coder des choses ultra simples etant a la portee de quiconque a l'aide de simples modeles)
- codage simplifier pour la grosse partie (les parties plus complexes type orchestration de services sont a la charge d'experts techniques/fonctionnels - on classifie les devs et on valorise enfin les experts - souvent oubliés dans les structures d'entreprise).
- ne plus avoir de problemes pour trouver des 'bras' (bac + 2 etc sont largement suffisants)
- tres simple a externaliser en off shore (sans risque)
- adapté au devops
- les devs font se qu'ils preferent, du code technique en jouant avec les technos/outils du moment
- reduire les couts et les delais (generation de code auto inclus les tests / deploiement est postulat de base dans ces archis)
- permet de donner de l'emploi a des gens debutants
- reduit le besoin de remunerer des experts a des tarifs prohibitifs (et se rendre dependant d'eux)
- Meilleure tracabilité et visibilité dans l'etape de dev (fini l'effet tunnel)
J'ai l'impression d'entendre un manager ... Pas etonnant que les jeunes talents `fuient` la France avec ce genre de discours!
A dire, je ne vois pas ce personnel comme appartenant à la "comptabilité" de par le fait qu'ils ne sont pas ... "comptable". Je parle du comptable, comme le terme le défini en tant qu'emploi et de rôle dans une société. L'homme aura toujours son importance mais je doute que son rôle en tant que "homme qui calcul et fait les comptes" va perdurer réellement pour les grandes entreprises (s'ils ont pas déjà disparu) et peut être pour les moyennes entreprises à terme quand les systèmes informatiques de ce type seront devenus abordable et la norme sur le marché et dans les pratiques.
Non je suis architecte dans cette nouvelle organisation - et je fais du dev sur les parties framework et orchestration de services; maintenant oui ca peut surprendre ce que j'ecris mais c'est juste le simple constat de la realité de beaucoup d'entreprises; la realité c'est que de plus en plus de projets passent dans ces archis et elles sont redoutables (mais n'ont pas que du - ce qui semble - negatif).
Certains nouveaux devs sont tres contents car ils arrivent a intégrer des equipes et a se former sur le tas en se basant sur bonnes pratiques.
Meme s'ils commencent tres simplement au debut. Les plus brillants (les jeunes talents comme tu dis) generalement se font remarquer rapidement et sont exfiltrés pour travailler sur des taches plus nobles.
Tout le monde en dev ne veut pas forcement se prendre la tete. Pour certains c'est un boulot comme les autres ou ils deroulent.
Ca fait gagner enormement de temps pour tout le monde. Fini le developpeur qui se forme ou qui grenouille dans son coin en reinventant la roue carree.
Tout le monde y trouve sa place et y trouve son compte au final.
Essayer c'est l'adopter.
On est en train d'essayer de faire ça chez moi mais j'ai du mal à croire qu'un dev lambda surtout formé en bootcamp puisse implémenter efficacement les règles métiers et surtout maintenir le truc surtout sur des vieilles applis qui nécessitent pas mal de connaissance transverse (BDD, système, etc.)
Pour l'an 2000 (et l'euro), pleins de gars (et de filles aussi) ayant fait un temps soit peu de science se sont vu offrir des postes en informatiques.La démocratisation du codage et des formations en informatique va-t-elle ruiner le marché de l'emploi IT de demain ?
Depuis on les a perdu.
Apprendre le développement aux enfants, pourquoi pas, mais ça n'en fera pas forcément des informaticiens. En tout cas, je ne suis pas devenu mathématicien ou physicien, moi !!!
C'est peut être ce qu'espère quelques grosses boites. Mais elles vont vites déchanter si il ne sort pas plus d'informaticiens que ça des écoles.
Et puis les clients sont de plus en plus exigent. On peut plus refourguer un gugusse qui trainait dans le couloir, ou jouer aux chaises musicales.
D'après les descriptions que j'ai eu de quelques fac/formation payantes dans le domaine informatique, par des anciens étudiants et stagiaires,
je peux affirmer que celui qui a un BTS ou un DUT ou un diplôme d'une école d'ingénieurs "à l'ancienne", aura toujours l'avantage.
Même on ne lui enseigne pas la dernière techno à la mode, il aura au moins les bases théoriques et techniques pour apprendre et évoluer tout le long de sa carrière.
Je ne suis pas sure que ce genre d'architecture soit très performante. Et quelle en est le cout pour le client, au final? parce si il faut des fermes de serveurs pour que ça tourne a peu prêt
Et un développeur, c'est pas un mollusque qui pisse du code à l'heure. A un moment, il faut comprendre ce qu'on fait, pourquoi on le fait, et si c'est pertinent de le faire.
Parce que dans ton descriptif, je ne vois pas ou se situe l'analyse fonctionnelle
Pourtant, c'est la mode le micro service et à peu près pour les raisons cités.
Le principe du micro service, c'est un peu comme le principe d'origine des commandes UNIX: chaque commande ne fait qu'une chose mais elle le fait bien.
Cordialement.
c'est exact mais ce qui importe c'est le résultat final aussi bref le projet informatique ( modalité vs finalité ) sauf à apprendre effectivement à programmer
Ce qui est marrant avec ce genre de sujet, c'est que tous les participants s'imaginent etre des bons developeurs.
Pour les personnes vraiment talentueuse, je vois pas en quoi une masse d'incompetents va poser soucis. Et puis on peut aussi esperer qu'avoir une plus grosse base de profils pourrai permettre un travail de meilleure qualite.
c'est une façon d'interpréter les choses donc de manière subjective.
Qui a écrit s'estimer être un bon développeur ?
non pas forcement de ferme de serveurs mais je parle d'appli d'entreprise (quelques serveurs redondés en l'occurence suffit), pas d'une simple appli desktop qui tourne sur un PC.Je ne suis pas sure que ce genre d'architecture soit très performante. Et quelle en est le cout pour le client, au final
Et un développeur, c'est pas un mollusque qui pisse du code à l'heure. A un moment, il faut comprendre ce qu'on fait, pourquoi on le fait, et si c'est pertinent de le faire.
Parce que dans ton descriptif, je ne vois pas ou se situe l'analyse fonctionnelle
Ben si justement avec les micro services, le boulot de dev se cantonne a coder des choses tres simples.
Tres facile a externaliser en offshore pour cette raison egalement. Le dev en inde ne voit qu'une partie sans savoir exactement a quoi elle sert.
Je crois que ca les arrange aussi car souvent les devs se focalisent sur la technique et les outils et le fonctionnel ne les passionne pas plus que ca (ils s'en foutent puisque rien ne garantit qu'ils changeront pas de projets a la fin de son petit dev. On a un bureau d'etude d'un millier d'indiens (tres bons techniquement) donc on peut pas lutter financierement (avec des salaires /4 a /8 minimum selon le profil par rapport a nos salaires en france). Quand bien meme ils mettent plus de temps a comprendre le peu de fonctionnel, avec un tel ratio (4 ou 8), ils continuent a etre peu cher et en quantité.
Oui je suis persuadé que le metier de developpeur sera tot ou tard ubérisé; les archis micro services s'y pretent idealement.
Il n'a pas besoin de connaitre le fonctionnel de l'ensemble mais juste de coder les briques autonomes qu'on lui demande de coder.
Visiblement tu n'as jamais pratiqué; tu es encore visiblement dans une vision d'il y a quelques années du developpeur tout puissant dont on attend tout.
Ce n'est plus indispensable dans le monde d'aujourd'hui. Le code sans plus value peut etre delégué a de simples dev; le code avec plus de valeur ajouté est valorisé a sa juste valeur; ceux qui sortent du lot en tirent partie.
L'analyse fonctionnelle et expressions des besoins est initiée puis evolue au fur et a mesure du projet (mode agile) - rien de nouveau la dedans.
Comme la complexité se deplace plutot sur la partie orchestration et n'impacte que tres peu les devs de base; pour ces travaux d'orchestration on ne met pas de simples developpeurs.
Aucun interet a ce que tout le monde soit expert en tout; qu'ils fassent 1ou 2 choses mais sans fautes.
C'est la recette pour se retrouver avec un fatras de frameworks empilés les uns sur les autres, des performances dignes d'un 8086 sur un Xeon 8 cores... et des années de maintenance assurées derrière... J'ai déjà vu ce genre de résultat dans des entreprises (et pas dans des petites)...
Si un mec me présente un truc comme ça, je le passe directement par la fenêtre du sixième étage... (j'ai droit à 7% de pertes)
Ca a toujours été l'argument depuis le début des années 2000, mais nombre de projets en Inde se sont cassé la gueule.
La plupart du temps, quand je suis en contact avec des indiens, ils sont un enième maillon d'une chaine pour des fiches anomalies.
Par exemple ils dispatchent les anomalies, et parfois sans grande intelligence, exemple en France je suis fournisseur de données à une appli nommée ABS basée dans notre structure en Suisse, qui digère les données, et les restitue en reporting à mes utilisateurs dans le bureau d'à côté. Quand ils ont une anomalie, ils ouvrent un ticket, et le ticket choit chez moi, jusque là c'est normal. Parfois, c'est moi qui ouvre un ticket, et comme ils voient "France" et "ABC", ils m'assignent le ticket. Je précise bien que je suis l'emetteur, et que si je pose une question à un business analyst c'est que j'ai besoin d'une réponse, mais le ticket revient invariablement chez moi ^^
Parfois, la logique binaire ne semble pas correspondre. Pour la même appli, un des fichiers contenant un type de produit XYZ n'est pas généré car la banque a décidé de ne plus utiliser ce type de produit. On attend donc un fichier qui bloque la chaîne. Je renvoie donc un fichier uniquement avec l'en-tête. Là on me dit que ça bugue parce que ça n'a pas de ligne. Je renvoie donc le mail validé du DG qui confirme qu'on en fait plus de produit. Mais rien à faire, ping pong de ticket me disant de renvoyer un fichier avec au moins une ligne de données
Quelques années auparavant, quand j'ai eu à bosser avec des Indiens en off-shore, ça a donné des trucs pharaoniques comme :
- le chef de projet indien se barre du jour au lendemain, pas de passation de connaissances
- les Indiens disent toujours oui, sont à 99% d'avancement, et la veille de la première mise en recette, les développeurs ne fournissent pas une seule ligne de code, "promis, le mois prochain"
- On leur envoie une maquette d'un écran HTML en entourant de rouge sous paint une list box pour attirer l'attention du point de règles et ils... développent en HTML en dur l'ovale rouge autour de la list box désespérement vide.
Aujourd'hui, en tout cas parmi les plus grosses sociétés, on vire de plus en plus les Business Analyst, ce sont les développeurs (prestas et internes) qui sont en contact direct avec les utilisateurs, les chefs de projet (internes) n'étant là que pour jouer de la balalaïka et récolter les lauriers sans qu'ils aient rien compris (c'était le cas sur mes deux précédentes missions, là sur cette mission mon CP connait parfaitement les enjeux et m'explique même du business mais il n'empêche que je suis en contact direct avec les utilisateurs).
Donc les Indiens à des milliers de kilomètres et plus quelques fuseaux horaires, qui reçoivent des specs par téléphone, j'y crois plus trop, là.
(par contre les Espagnols, les Portugais...)
- So.... what exactly is preventing us from doing this?
- Geometry.
- Just ignore it !!
****
"The longer he lived, the more he realized that nothing was simple and little was true" A clash of Kings, George R. R. Martin.
***
Quand arrivera l'apocalypse, il restera deux types d'entreprise : les pompes funèbres et les cabinets d'audit. - zecreator, 21/05/2019
Ha oui ? Ce n'est plus tendance le business analyst ?
De mon expérience c'est toujours un épic fail de mettre en relation un dev' et un end user. Je comprends bien que ça coûte de rajouter une couche mais c'est quand même efficace.
Sinon les indiens de la SoGé étaient bons quand je les fréquentais. (Ils étaient internes et leurs business anlyst presta)
Tout dépend de ce que l'on entend par "développeur"
Si c'est juste un pisseur de code... Ou si c'est un gars qui a peu de plus de jugeote et de maitrise de son sujet...
Tous les développeurs ne sont pas de simples pisseurs de codes
Tous les pisseurs de code ne sont pas de grands développeurs capables de cerner correctement un besoin et de l'intégrer dans son code sans déstabiliser l'application tout entière
D'un autre coté tous les analystes ne sont pas capables de cerner correctement les implications des développements qu'ils imaginent et réclament aux développeurs quand ils savent à peine cerner les demandes et les besoins des utilisateurs et des clients...
Y'a des bons (même des très très bons) et des mauvais (voire carrément plus dans la médiocrité) partout de mon expérience
Là où ça ne va pas c'est quand y'a que des mauvais avec des mauvais et des manches à couilles...
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager