[Covid-19] Reconversion informatique : oui mais dans quoi ?

Répondre
Partager Rechercher
Citation :
Publié par Gardien
L'idéal aussi serait que les formation se spécialisent... Car une formation en "informatique" généraliste, ben ca voit trop de chose de façon trop superficielle. Donc avoir des notions sur un peu tout les domaines OK, mais il faut une certaine "spécialisation" pour obtenir des competences / expertises interessante pour un employeur.
Je suis moyennement d'accord. Je trouve au contraire qu'avoir une formation assez large apporte une culture générale sur l'informatique qui est compliquée de trouver ensuite (notamment toute la partie théorie). J'avais un prof de logique (séquent, lambda calcul ...) qui nous disait "ça vous servira probablement pas à tous mais au moins vous savez que ça existe/quoi chercher si vous tombez sur un problème de ce genre", ce qui est je pense l'intérêt d'une formation assez large (je parle d'une formation informatique pure, pas des types en d'écoles d'ingés qui font un M2 info recherche à l'arrache en étant dispensés des cours pratiques car trop mauvais en programmation par exemple ).

Bien sûr c'est pas pour ça qu'il ne faut pas aussi proposer des cours en lien avec ce qui se fait en entreprise (en faisant venir des pros en intervenant, ce qui manque dans les facs clairement), mais de toute façon jamais un junior n'apportera une "expertise" à son employeur à son embauche.

Après comme tu le dis tout le monde s'en fiche des diplômes au bout de quelques années. Je travaille avec des ingés d'un peu partout (Europe, US...) et les études qu'on a fait n'intéressent personne. Par contre il faut savoir prouver/justifier ses compétences. On parle beaucoup de pénurie en informatique, on devrait plutôt parler d'une pénurie de personnes compétentes ce qui n'est pas la même chose.
Citation :
Publié par Nelphit
"ça vous servira probablement pas à tous mais au moins vous savez que ça existe/quoi chercher si vous tombez sur un problème de ce genre"
Je suis complètement d'accord sur ce point. Un bon développeur est capable de comprendre des anomalies réseaux, des incohérences de bases de données, des problèmes sur des vues et surtout de partir sur des analyses "hors contexte" pour trouver la cause d'un problème "inconnu".

Pour moi, un bon développeur est d'abord un bon informaticien d'où une culture/formation généraliste en informatique n'est pas à renier : savoir correctement utilisé la suite Office, gérer son projet, faire des analyses réseaux/bases de données pour connaitre la connectivité/cohérence des données, avoir du recul pour penser au nombre de clics quand tu conçois une vue/application et à son ergonomie.

Mais un bon développeur est également bon en algorithmie pour justement pouvoir faire une conception au plus prêt du besoin avec tout le contexte qui lui sera transmis/à disposition.

Et tu auras beau faire toutes les formations que tu trouveras, cela ne s'acquière qu'avec la pratique avec des cas concrets

Citation :
Publié par Nelphit
mais il faut une certaine "spécialisation" pour obtenir des competences / expertises interessante pour un employeur.
Pour moi : 2 ans de culture généraliste après le bac suffisent, au moins 1 ans de spécialisation strict minimum

Quand t'es junior, on s'en fout de tes compétences, on veut juste savoir si tu réfléchis et communique bien, c'est l'employeur qui te fera monter en compétences. Le diplôme sert juste à "justifier ton cursus" (après oui certaines écoles type EPITA/EPITECH permettent d'accéder à de meilleurs postes, faut pas se le cacher, mais la formation est hard ^^). Mais ce n'est pas vraiment le débat ici ^^

Dernière modification par cunoverabair ; 19/11/2020 à 12h38.
Citation :
Publié par Oopsrongchan
J'ai survolé vos réponses.

Quelques questions :

Quand on part de zéro, les formations en 6 mois web dev full stack valent pas grand chose ? ( Wilde code School, Digital campus, Open Classroom ou O'Clock par exemple) Oui, à distance.
J'aurai 2 ans d'ARE devant moi, si je complète une de ces formations avec de la formation personnelle, je peux arriver à quelque chose ?
Ou veux mieux se spécialiser ?

Sachant que j'ai pas le rêve de devenir une super star de la programmation et gagner des myions, juste être un tâcheron employable, ou mieux, un tâcheron indépendant.
Ces formations qui emploient le terme "full stack" veulent juste dire qu'on apprend à faire des trucs fonctionnels à la fois en front et en back, sans se spécialiser dans l'un des deux.
Mais à chaque fois que j'en parle à un dev, comme on le voit ici, ils réagissent comme si les formations prétendaient faire de l'élève un cador à la fois en front et en back. Plus clairement, comme si c'était par opposition à des dev spécialisés qui ne seraient capables de faire que du back. C'est évidemment pas du tout le cas, c'est juste pour dire que tu vas apprendre comment faire du back, et aussi du front, pour pouvoir sortir un site web qui ne soit pas juste du HTML.

Moi je suis en train de finir Le Wagon, qui se fait en 9 semaines très intenses. De tous les feedbacks qu'on a, les alumnis n'ont aucun mal à trouver du boulot, que ce soit en free ou en entreprise. Et je précise que cette facilité à trouver du boulot m'a aussi été confirmé de l'autre côté du miroir par des dev confirmés en activité (pas passés par le wagon).
Par contre, on est aussi parfaitement mis en garde sur le fait que ces 9 semaines ne donnent que des bases et des manières d'apprendre pour continuer de monter en compétence.

Avec 2 ans d'ARE… tout dépend de ta situation exacte bien sûr, mais si tu as pas des charges dans tous les sens, je dirais t'as tout ton temps pour faire ce que tu veux. Par ex si t'es pas sûr tu peux très bien faire la formation openclassrooms qui est, me semble-t-il, pas chère du tout. Quitte à faire un truc genre le wagon après, ou bien plus long…
En tout cas "se spécialiser" dès le départ n'a pas vraiment de sens à mon avis, c'est justement quand on part de 0 que ces formations courtes sont intéressantes.
J'ai fait une formation l'année dernière en dev web. J'ai trouvé autre chose depuis et je ne code pas, mais le simple fait d'avoir passé un diplôme à mon age a été un des facteurs de ma situation actuelle, c'est assez bien vu de montrer qu'on n'a pas le cerveau rouillé. Par contre pour cela il faut favoriser les formations connues ou proposant des diplomes d'état. La Momo's school of coding c'est à éviter.
Sur le long terme je vais probablement perdre toute compétence technique, mais ca aura été utile pour aider à mieux comprendre les équipes de dev que je dirige et leurs problématiques. (On m'enlèvera pas de l'idée qu'un directeur de projet qui a zero compétence métier est un handicap)
Citation :
Publié par Quint`
[...]
Merci pour ton témoignage, ça me conforte dans mon choix.
Citation :
Publié par La Hutt Finale
c'est assez bien vu de montrer qu'on n'a pas le cerveau rouillé.
C'est aussi et surtout à moi que j'ai envie de montrer que j'ai pas le cerveau rouillé
Il y a quand même énormément de jobs de planqués en informatique, où il n'y a pas besoin d'être bon (sous-entendu expert, avec pleins d'expérience etc) pour réussir. Le retour de Quint ne m'étonne pas du tout.

Perso je travaille dedans, avec relativement de succès, et je suis passionné à 0%. Dans mon école des gens rentraient chez eux compiler des noyaux linux, quelle idée. Nul doute que si t'es passionné (et pas un connard hautain, c'est honnêtement plus important que le skill ou alors t'as intérêt à être VRAIMENT bon) tu auras beaucoup plus de succès qu'un mec comme moi qui osef un peu, mais tu peux atteindre un niveau de salaire assez haut, surtout si vous êtes ouvert à l'international.

Un conseil que j'aurai c'est de tater le terrain, et faire ce que vous avez envie, que vous kiffez. C'est utile d'éviter de développer de mauvaise habitudes, mais au début tu ne connais rien ou presque, donc passer du temps à faire les choses plutôt que développer un plan soit-disant optimal qui ne sera jamais exécuté me parait productif. Peu importe ce que vous choisirez, ça sera utile et vous apprendrez des choses.

Dernière modification par Mimu ; 20/11/2020 à 10h50.
Citation :
Publié par cunoverabair
[...]


Pour moi : 2 ans de culture généraliste après le bac suffisent, au moins 1 ans de spécialisation strict minimum

Quand t'es junior, on s'en fout de tes compétences, on veut juste savoir si tu réfléchis et communique bien, c'est l'employeur qui te fera monter en compétences. Le diplôme sert juste à "justifier ton cursus" (après oui certaines écoles type EPITA/EPITECH permettent d'accéder à de meilleurs postes, faut pas se le cacher, mais la formation est hard ^^). Mais ce n'est pas vraiment le débat ici ^^
EPITA => les mecs sont bon/tres bon. Un moyen d'EPITA explose un tres bon d'EPITECH

EPITECH => c'est un peu mieux qu'une IUT de mon point de vue, Rien de "hard" dans leur formation.
Citation :
Publié par MiniTiZ
EPITA => les mecs sont bon/tres bon. Un moyen d'EPITA explose un tres bon d'EPITECH

EPITECH => c'est un peu mieux qu'une IUT de mon point de vue, Rien de "hard" dans leur formation.
Je propose un match de catch dans la boue

Alors je ne prends pas parti puisque je n'ai pas fais d'études supérieures.
Toutefois une brève recherche me fait dire qu'EPITA est une école d'ingénieur et qu'EPITECH est une école spécialisé dans le coding donc ce n'est pas réellement pertinent de comparer.
Citation :
Publié par Mimu
Il y a quand même énormément de jobs de planqués en informatique, où il n'y a pas besoin d'être bon (sous-entendu expert, avec pleins d'expérience etc) pour réussir. Le retour de Quint ne m'étonne pas du tout.
Ah je te rassure: y'a pas qu'en informatique, loin de la.
Citation :
Publié par Djunn
Je propose un match de catch dans la boue

Alors je ne prends pas parti puisque je n'ai pas fais d'études supérieures.
Toutefois une brève recherche me fait dire qu'EPITA est une école d'ingénieur et qu'EPITECH est une école spécialisé dans le coding donc ce n'est pas réellement pertinent de comparer.
EPITA est vraiment tournée sur le dev avec une vrai sélection. T'as un ingénieur qui sera tech aussi.
EPITECH est juste une école où tu vas acheter un diplôme. Leur sélection c'est si tu as la tune, tu rentres.


C'est pas pour dénigrer. Juste que si j'ai le choix entre les 2 profiles en sortie d'école , j'hésite meme pas

Dernière modification par MiniTiZ ; 20/11/2020 à 12h51.
Citation :
Publié par Mimu
Il y a quand même énormément de jobs de planqués en informatique, où il n'y a pas besoin d'être bon (sous-entendu expert, avec pleins d'expérience etc) pour réussir. Le retour de Quint ne m'étonne pas du tout.
Je pense pas que c'est une question de planque, c'est juste que comme dans tous les domaines, il y a un large éventail de compétences mais aussi de niveau. Clairement une formation comme Le Wagon que je fais, c'est affiché dès le début "vous deviendrez pas développeur chez Google". Le but c'est d'être capable de faire des trucs vendables à des clients, ou d'avoir les bonnes bases pour être ensuite pris en main par une entreprise. Ce qui inclut les bonnes pratiques, pas juste du code.

Moi clairement je fais ça pour vivoter en freelance tout en continuant d'apprendre, on verra bien où j'en suis dans un ou deux. C'est d'ailleurs le cas de beaucoup des gens qui font ces formations (pour ceux qui font du dev "pur" après, par opposition à être product manager ou autre métier annexe).
Citation :
Publié par MiniTiZ
C'est pas pour dénigrer. Juste que si j'ai le choix entre les 2 profiles en sortie d'école , j'hésite meme pas
Moi c'est le genre de trucs qui ne m'intéresse pas du tout, et j'ai jamais réussi à corréler le niveau de quelqu'un avec son école, que ce soit des écoles/facs FR ou à l'international (du genre EPFL pour citer un truc connu en Europe).
Citation :
Publié par Nelphit
Moi c'est le genre de trucs qui ne m'intéresse pas du tout, et j'ai jamais réussi à corréler le niveau de quelqu'un avec son école, que ce soit des écoles/facs FR ou à l'international (du genre EPFL pour citer un truc connu en Europe).
Je parle vraiment en sortie d'école, l'exp fera foi plus tard. Tu as 2 profils qui ont la même envie en entretien, tu dois en choisir un... tu prends le moins de risque, c'est tout.

Je fonctionne uniquement par connaissance personnellement, aucune confiance dans les formations. Si on me dit que c'est un génie ou qu'il a du potentiel, je dis OK et osef de son école
Message supprimé par son auteur.
Citation :
Publié par Djunn
Toutefois une brève recherche me fait dire qu'EPITA est une école d'ingénieur et qu'EPITECH est une école spécialisé dans le coding donc ce n'est pas réellement pertinent de comparer.
Pour moi, c'est des écoles qui viennent tapiner dans les forums pour prépa pour essayer de récupérer les élèves qui se sont trompés d'adresse et n'ont pas le niveau pour passer un concours. Entre les deux, je fais pas vraiment le distinguo. Après, ça a peut être changé par rapport à l'époque où j'ai fait mes études, mais j'ai comme un doute.
Si l'OP souhaite un boulot stable en informatique qui paie convenablement (mais ou il n'y a pas les salaires des GAFAM), il y a les concours de la fonction publique qui sont accessibles à bac+3 pour les catégories A.

Les plus intéressants : Finances (DGFIP ou Douanes)
https://www.economie.gouv.fr/recrute...iques-externe#
https://www.economie.gouv.fr/recrute...dexploitation-
Environ 3k€ net en début de carrière aux douanes, un poil moins à la DGFIP.

Sinon il y a aussi le concours d'ingénieur des SIC, qui est un corps interministériel mais porté par le MININT. Le concours externe est plus "simple" mais n'est ouvert qu'à bac+5 :
https://www.interieur.gouv.fr/A-votr...r-des-SIC-2020
La rému est de 2500€ net au premier échelon en RP et 2100€ net en province. Moins intéressant au début mais grades supérieurs plus accessibles pour un ingénieur info qu'aux Finances (ça implique cependant de se projeter sur une carrière longue).

Je parle de ceux que je connais au sein de la FPE, il y en a plein d'autres évidemment.
Je ne crois pas qu'il y ait de la discrimination au type de diplôme, dès lors que le pré-requis de niveau académique est rempli.
Un autodidacte qui potasse un peu peut donc tenter sa chance.
(edit : pour le concours externe ISIC, il faut apparemment un bac+5 en info...).

Accessoirement, ça permet de faire un job "utile", ce qui n'est pas forcément évident dans l'informatique, entre les postes d'ingesclaves des marchands de viande SSII et les tous ces bullshit job a visée marketing. Enfin ça dépend dans quelle administration on tombe je suppose.

Dernière modification par Zuglok ; 20/11/2020 à 22h41.
La Fonction Publique d’État, tu peux parfois troquer un ingé commercial qui te vend à n'importe qui en prétendant que tu sauras faire n'importe quoi des SSII, par le lieu où les projets n'avancent jamais pour causes de disputes infernales à un niveau N+2, N+3, et où tu passes ton temps à adapter dix fois vingt fonctionnalités sur une période de deux ou trois ans parce que machin est venu à bout de bidule puis bidule a su refaire valoir ses vues quelques mois plus tard.

Ce dont je me rends compte aujourd'hui, c'est que le métier est devenu plus difficile.
Il y a un très très grand écart entre tout ce que l'on est susceptible de demander.

Le full-stack, pour un employeur, cela peut parfois couvrir tout cela en même temps :
Côté infrastructure : on te demande de plus en plus de savoir gérer un peu ou assez bien Docker ou des machines virtuelles. Ce n'est pas si simple. C'est limite si on se choque si tu ne maîtrises pas d'emblée Docker compose.

Côté métier : tout est en framework, pour le bien pour le mal. Spring-boot, par exemple, est très bien, mais il réclame un apprentissage pour bien le maîtriser.

En vrac, en intermédiaire : les évolutions folles de langages, les process de génération de code automatisés, les lambda, Kotlins, Scala et autres, tous les trucs qui veulent changer ta manière d'écrire le code pensant que tu irais plus vite ou mieux alors qu'ils sont parfois générateurs d'obscurité...
Qui maîtrise le C++ 17 ? Qui saura maîtriser le C++ 20 ? Il est devenu si fou qu'il y a même un mouvement de retour au C.

Côté front : des pages web classiques, on est passé au Javascript hard, puis à l'Angular, puis au React, c'est tout un monde à maîtriser. Avec les bibliothèques d'art-déco, et le npm pénible.
Un mot sur le low-coding : fuir les boites qui en proposent. Ça n'apporte que des ennuis.

L'informatique couvre un champ très vaste. Le full-stack, il y a un risque de devenir un jack-of-all trades but master of none, même si, réussi, on est très utile aux entreprises.
Très utile, mais avec ses limites. Moyennant beaucoup de travail (cinq à sept ans) tu attendras la limite de la fonction "à ce moment-là", et il faudra te tenir à jour, sur une période de cinq ans deux technos majeures que tu connaissais sur cinq disparaissent typiquement, et en dix ans, tout est remplacé.
Citation :
Publié par Caniveau Royal
Le full-stack, pour un employeur, cela peut parfois couvrir tout cela en même temps :
Côté infrastructure : on te demande de plus en plus de savoir gérer un peu ou assez bien Docker ou des machines virtuelles. Ce n'est pas si simple. C'est limite si on se choque si tu ne maîtrises pas d'emblée Docker compose.
C'est sûr qu'on demande aux devs de voir un peu plus loin que leur IDE, et de plus en plus souvent de gérer les déploiements en prod ou d'être d'astreinte sur les services en prod. C'est le cas chez nous: you build it, you run it. Mais en étant dans la bonne boîte l'apprentissage de tout ça vient avec le temps.

Après méfiance des boîtes qui essayent de recruter des "devops" qui en fait fera le travail des devs + des ops, ce sera l'échec assuré. Ça reste deux mondes distincts même si on va dire que chaque côté s'intéresse plus à l'autre.

Et oui le métier évolue, parfois (trop souvent) porté par la hype, un bon ingé en plus de ses compétences techniques ce sera aussi celui qui saura faire les bons choix de technos/outils. Mais tout n'est pas à jeter dans ce qui apparaît actuellement.

Citation :
Côté métier : tout est en framework, pour le bien pour le mal. Spring-boot, par exemple, est très bien, mais il réclame un apprentissage pour bien le maîtriser.
J'espère que j'aurai jamais à travailler de nouveau avec cette stack de l'enfer (les spring boot/spring cloud, et tous les trucs moisis du style hibernate/aspectJ etc...) C'est le meilleur moyen de dégoûter un junior du développement (même si c'est vrai que c'est une stack très présente en SSII, ce qui veut tout dire imo).
Après il il a quand même pas mal de boîtes qui évitent ces frameworks.
Citation :
Publié par Nelphit
J'espère que j'aurai jamais à travailler de nouveau avec cette stack de l'enfer (les spring boot/spring cloud, et tous les trucs moisis du style hibernate/aspectJ etc...) C'est le meilleur moyen de dégoûter un junior du développement (même si c'est vrai que c'est une stack très présente en SSII, ce qui veut tout dire imo).
Après il il a quand même pas mal de boîtes qui évitent ces frameworks.
C'était justement ce que je me refusais à faire à ma sortie d'études en développement Java/J2EE, il y a tellement de framework, et de pratiques, qu'au final en apprendre une sans être dans le monde du travail n'a pas de "sens". J'ai eu la chance d'intégrer une boite SAP sur laquelle j'ai pu mettre en pratique mes connaissances "généralistes Java/J2EE" pour monter en compétences. Une fois que je m'étais fait une bonne idée "du monde du travail et de ses attentes", une autre offre m' fait basculer dans le monde Sapiens et je m'y plais beaucoup plus car cela mêle "presque" tout ce que je sais faire/aime en informatique
Citation :
Publié par Nelphit
Après méfiance des boîtes qui essayent de recruter des "devops" qui en fait fera le travail des devs + des ops, ce sera l'échec assuré. Ça reste deux mondes distincts même si on va dire que chaque côté s'intéresse plus à l'autre.
Un "devops" (j'en suis un) n'est pas quelqu'un qui dev et qui fait de l'ops.

je suis issue d'une reconvertion profesionnelle bac +2 en 8 mois (admin système linux), mon poste (et mon salaire) est celui d'un ingénieur.
Je n'ai aucune certification même si j'ai le niveau pour passer une LPI et quelques certifs redhat mais je m'en fout, je ne suis pas freelance et je ne suis plus dans une S2I.


Sous ce terme fourretout :

Tu a des spécialistes assez "management" qui vont piloter la transition, mettre en place des process, etc..., si il y a bien un devops qui cadre c'est lui.

Tu a des techniques qui sont issue majoritairement du monde du dev (mais aussi de monde ops), le vrai terme serait plutôt pipeline and tools engineer (c'est moi).

Alors pour le techiques c'est quoi, ben c'est de l'automatisation à tout les niveaux, codage d'outil (shell, python, go), pipeline, déploiement (ansible, outil de CI/CD) avec k8s/docker (c'est plus simple pour notre métier, mais quant tu à de la vieille architecture ca marche aussi).

Donc, je résume, le script (3/4K ligne, je sais pas si c'est du script à ce niveau la) qu'utilise le fonctionnel pour déployer dans les différents environnements afin de faire les tests fonctionnel puis de faire partir en prod ---> c'est moi.
Les scripts/wrapper pour déployer des bases de données et leurs synchro avec la prod anonymiser --> c'est moi.
Les pipelines de déploiement des différents environnements pour l'intégration continue --> c'est moi.
Le déploiement des serveurs pour les différents environnements automatisé sous ansible --> c'est moi.
Le "tuning" des linux en poste client pour automatisé certaines taches afin de faciliter la vie des dev --> c'est moi.
La vieille technologique pour trouver des extensions, des IDE, des outils pour que le dev ai le plus de confort possible dans son dev ---> c'est moi.
La métrologie/supervision des applicatifs des dev ---> c'est moi.

le développement des applicatifs c'est pas moi
Configurer un vlan, connecter les hyperviseurs, mettre en place les routeurs, la gestion des certificats, mettre en place le HA au niveau système (ceph) etc.. c'est pas moi.

Les frontaux et service mesh (haproxy,nginx,apache tomcat, envoy....) --> travail conjoint.

Bref, n'importe quel adminsys "linux" à les compétences nécessaires pour faire mon taff, alors pourquoi c'est un métier distinct :

+ Je file un coup de main aux devs pour la mise en place de leurs postes et je suis à l'écoute de leurs besoins.
+ Je file un coup de main au fonctionnel, afin qu'ils soit totalement autonome grâce à l'automatisation.
+ Je file un coup de main aux ops pour les prérequis applicatifs, les tests de charges etc..
+ Je file un coup de main aux datascientist pour leurs apprendre les process de dev (qualité de code etc..), automatiser leurs modèles, déployer leurs datalake and co avec des pipelines.

Donc du coup, quant il s'agit de mettre en place un truc, je comprend le besoin et les contraintes du dev, et de sa mise en place coté ops, je peux ainsi priorisé voir orienté sur autre solution qui soit le moins contraignant pour le dev, mais aussi pour l'ops avec des notions de sécurité.

Que ce soit les devs, les ops ou les datascientist, voir les fonctionnels aucun ne va m'embrouiller avec des termes incompréhensible...

Mon métier est d'automatiser, et d'assurer la bonne entente, la bonne compréhension afin que ce ne soit pas deux monde distincts.

Alors, oui, on génère du code qui passe des test unitaire, de linter, avec des revues de code, on a des méthodes d'organisation de travail qui sont proche de l'agile/kanban, on versionne tout, tout est "infrastructure as the code", on travaille avec des API, on est capable de faire de la revue de code et d'avoir un avis sur la "qualité de code".
Mais on est loin, très loin du niveau technique d'un dev senior niveau architecture, rapidité, optimisation, algorythmie et connaissance des frameworks, par-contre, je dois connaître maven, ant, npm, yarn, nexus, git un peu mieux que la moyenne.

Toutefacon, les ops de nos jours, utilise tout ca aussi.

Mais un devops n'est pas un ingénieur qui gère l'infra et qui dev l'applicatif, et ce n'est pas deux mondes distincts, c'est le même monde avec deux spécialités différentes qui travaille dans le mm but --> que le service réponde aux besoins.

Si je devrais résumer je suis en support des ops et de devs.

p.s : Docker-compose (c'est de la merde), enfin, non, mais à l'usage tu vois vite arriver les contraintes de ce genre d'outils quant ils sont intégrés dans un "tout", si c'est juste pour vite fait déployer des containers sur un poste, ca fait le taff.

Dernière modification par derioss ; 31/12/2020 à 16h13.
On part en H.S par rapport au post initial (peut être que ça mériterait un split), mais ce que tu me décris ici est je trouve une dérive du Devops qu'on voit souvent: on avait deux silos (dev et ops), maintenant on en a 3 (dev, ops, "devops").
Mais je comprends ton poste pour avoir fait ça aussi chez un grand groupe où c'est tellement lent à faire changer les choses qu'ils créent ce genre d'équipes intermédiaires, qui se chargent de la CI/CD, automatisation (Ansible, Terraform, Puppet, conteneurs...), monitoring etc...

Etant lead chez un cloud provider (je donnerai pas plus de détails, je tiens à mon anonymité jolienne ) je connais bien le sujet. Et Devops ne devrait pas être un métier ou une équipe.

Chez nous, et dans plus en plus de boites (bon peut être pas en France, ma boite n'est pas FR d'ailleurs), le but est de rendre les équipes de dev autonomes. Les pipelines de CI, le déploiement en prod, le fait que les applications fournissent des métriques pertinentes... sont des sujets gérés directement par les devs du projet. Les dev sont également oncall sur leurs projets (j'y suis actuellement d'ailleurs), donc si ça plante c'est le dev qui est réveillé en premier.

Les ops, eux, fournissent l'outillage aux développeurs pour que tout roule. Par exemple, si les dev sont responsables d'exposer des métriques, de gérer l'alerting, de fournir des logs corrects et pertinents etc... C'est les ops qui fournissent et maintiennent les outils nécessaires (plateforme de logs, Prometheus ...) qui seront "consommés" par les devs.

Pareil pour les déploiements en prod: c'est géré directement par les équipes de dev, qui choisissent leurs stratégies de déploiement (le but étant que ça parte rapidement en prod), écrivent si on est sur du kube par exemple les manifests des applications... Par contre c'est les ops qui vont maintenir l'infra (clusters kube ou autre). Et bien sûr ça automatise à fond des deux côtés, ce qui permet de gérer des infras/projets conséquents avec des équipes réduites.

Ensuite, tout est une histoire de communication entre les dev et les ops. Chaque équipe doit savoir ce que les autres font, les décisions impactant tout le monde doivent être pris en commun, et chacun doit pouvoir aider l'autre si besoin (ça peut être assez poreux parfois, surtout dans les boîtes où le produit est de la tech).
Pour moi, résumé très très rapidement, c'est ça le devops.
Citation :
Publié par Nelphit
On part en H.S par rapport au post initial (peut être que ça mériterait un split), mais ce que tu me décris ici est je trouve une dérive du Devops qu'on voit souvent: on avait deux silos (dev et ops), maintenant on en a 3 (dev, ops, "devops").
Mais je comprends ton poste pour avoir fait ça aussi chez un grand groupe où c'est tellement lent à faire changer les choses qu'ils créent ce genre d'équipes intermédiaires, qui se chargent de la CI/CD, automatisation (Ansible, Terraform, Puppet, conteneurs...), monitoring etc...

Etant lead chez un cloud provider (je donnerai pas plus de détails, je tiens à mon anonymité jolienne ) je connais bien le sujet. Et Devops ne devrait pas être un métier ou une équipe.

Chez nous, et dans plus en plus de boites (bon peut être pas en France, ma boite n'est pas FR d'ailleurs), le but est de rendre les équipes de dev autonomes. Les pipelines de CI, le déploiement en prod, le fait que les applications fournissent des métriques pertinentes... sont des sujets gérés directement par les devs du projet. Les dev sont également oncall sur leurs projets (j'y suis actuellement d'ailleurs), donc si ça plante c'est le dev qui est réveillé en premier.

Les ops, eux, fournissent l'outillage aux développeurs pour que tout roule. Par exemple, si les dev sont responsables d'exposer des métriques, de gérer l'alerting, de fournir des logs corrects et pertinents etc... C'est les ops qui fournissent et maintiennent les outils nécessaires (plateforme de logs, Prometheus ...) qui seront "consommés" par les devs.

Pareil pour les déploiements en prod: c'est géré directement par les équipes de dev, qui choisissent leurs stratégies de déploiement (le but étant que ça parte rapidement en prod), écrivent si on est sur du kube par exemple les manifests des applications... Par contre c'est les ops qui vont maintenir l'infra (clusters kube ou autre). Et bien sûr ça automatise à fond des deux côtés, ce qui permet de gérer des infras/projets conséquents avec des équipes réduites.

Ensuite, tout est une histoire de communication entre les dev et les ops. Chaque équipe doit savoir ce que les autres font, les décisions impactant tout le monde doivent être pris en commun, et chacun doit pouvoir aider l'autre si besoin (ça peut être assez poreux parfois, surtout dans les boîtes où le produit est de la tech).
Pour moi, résumé très très rapidement, c'est ça le devops.
je ne suis pas en "silo", je suis en charge de cette partie la et je fais les issues qui concerne l'automatisation et le déploiement applicatif tout en étant rattaché sur le board adminsys, car si j'ai un trou, je peux intervenir sur leurs issues.

Mon titre de poste c'est ingénieur devops, mon métier réel c'est pipeline and tool engineer, mais on va pas faire chier les RH (hein).

C'est juste que c'est plus simple pour eux de passer par moi, vu que pour mon poste la priorité c'est eux, leurs demandes sont forcément prioritaire, mais ce n'est pas une obligation vu que ce n'est pas compartimenté.

Le directeur du SI et son adjoint sont capable de faire de l'adminsys et du devbackend même si ils sont en charges du management à l'heure actuelle, si il y a urgence, il y a urgence.

Bref pour notre équipe, le SI est au service du métier, il n'y a pas de concurrence, pas de compartiments pas de bullshit.

Après, si demain je pars en vacance, les deux adminsys peuvent prendre mes issues, voir un dev backend senior, et le RSSI aussi et son adjoint (mm si ils ont autre choses à faire), la moitié de l'équipe peut importe la formation de base à des compétences devops.

Chez nous tout le monde comprend le shell (enfin pas les fronts), tout le monde est capable d'utiliser ansible/docker/gitlab-ci (mm les fronts), beaucoup sont capable de config plusieurs types de frontaux mais tu peux pas de demander un dev back ou un adminsys, de connaitre sa spécialités sur le bout des doigts et d'utiliser les conteneurs de manière sécurisé, de déployer tout les outils de métrologies, d'être à l'aise avec toute les techno open-source utiliser en infra, de connaître le matériel, de savoir coder en JS, python, java sur plusieurs framework (tout en passant nos exigeance de qualité de code), de maitrîser tout les niveaux d'abstraction entre les déploiements et la virtualisation imbriqué etc.. etc..

(enfin j'en connais, des gas comme ca, mais ils sont a 100K/annuel et travaille en SOCS), et c'est pas le genre de gas que t'arrive à capter aux recrutements sur une PME mm si notre stack technique et sefl-made, moderne et full open-source.

Je trouve justement que l'étendu de la stack technique, sa complexité et sa charge de travail pour rentrer vraiment dans la philosophie devops tout en maintenant une infra as the code est assez importante pour avoir un ou deux spécialistes.
Et que tu es un voir plusieurs gas spécialisés, ou une répartition de charges de travails sur tes senior pour faire le boulot dépend du contexte, de la taille de ton équipe.. et de ton legacy.

Et que du moment que t'abat les murs pour que tout ton SI soit au services du métier, le reste c'est de la sémantique.

Dernière modification par derioss ; 31/12/2020 à 17h15.
Citation :
Publié par (0)Draki
Ca n'a (malheureusement) plus beaucoup de sens.
Y'a des ingé a 2k-2k5 brut
Je ne suis pas Ingénieur d'école, mais mon poste l'est.

Des ingénieurs d'école qui on un poste de technicien oui il y en a, j'en ai vu surtout des sous-traitants et qui attende la promotion "chef de projet".

Maintenant, sur toulouse, si tu veux recruter un adminsys linux, un dev backend ou frontend passionné avec 2/3 ans XP mini avec des softs skills qui cadre avec la philosophie devops c'est chaud, il nous faut entre 8 et 14 mois pour en trouver un et on est sur du 37K pour un junior confirmé au mini.
Et sur un dev backend java senior qui en plus à les compétences devops, alors la... putain ca pique sec.

Si t'en a 2500 brut/mensuel (je te prie de me /w les profils).

Sortie de formation mon premier poste que j'ai accepté c'est 24K brut annuel, un CDI de chantier, avec 3 mois gratuit car j'ai vendu un POE avec, mais j'était sur un poste ingé en sous-traitant rattaché à une très gros trucs.
C'était le deal, mais des que tu a 2/3 ans d'xp tu commence à pouvoir choisir un salaire décent et une stacks technique intéressante.

Mais c'est la première année qui je trouve est la plus dure même pour quelqu'un qui sort avec un master, faut avoir la chance d'avoir un poste qui te permette de capitaliser à bloc ton expérience (et en reconversion j'en parle mm pas comme c'est chaud.)

Dernière modification par derioss ; 31/12/2020 à 17h25.
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés