Vers une pénurie de salariés qualifiés ?

[aleph-zero]

https://www.usinenouvelle.com/editorial ... ce.N634438


Mon taf m'amène à assurer des prestations dans pas mal d'entreprises (domaine technique), et c'est clair que le recrutement de personnel qualifié devient plus problématique pour elles.

En vrac :

une qui cherchait un cadre métallurgiste, 10 réponses, seulement trois profils en accord avec la recherche.

Une cherchait un métallographe, 0 réponse en six mois, même pas un candidat.

Un cadre qui quitte sa boite pour un autre taf deux fois mieux payé (Luxembourg), et l'entreprise est dans la panade pour le remplacer.

Investissement pour développer de nouveaux produits, mais difficultés à trouver le personnel qui va avec.

Cela fait 10/15 ans que l'on dit que l'industrie c'est mort en France. Donc moins de personnes sont motivées pour faire des études dans le domaine, et pourtant, il y a du taf. Et à plusieurs niveaux (un soudeur compétent et spécialisé peut faire des salaires supérieurs à certains petits cadres).

C'est encore léger, mais certaines entreprises commencent à revoir à la hausse leurs grilles de salaires, pour intéresser de meilleurs profils.

Enfin la « métallurgie » c'est large hein ? Les constructeurs de matériel informatique ou électronique sont dans la branche métallurgie. C'est pas pour rien que l'UIMM est la branche la plus riche du MEDEF.

[Utilisateur supprimé]

..........

[moinsdewatt]

Les salariés qualifiés c'est pas que les geeks pointus de l'informatique. On comprend même pas leur posts......

[slash33]

Les salariés qualifiés c'est pas que les geeks pointus de l'informatique. On comprend même pas leur posts......

Amha c'est pareil dans n'importe quel jargon. Je n'ai toujours pas compris la moitié de ce que m'a dit un expert en RDM béton la dernière fois. Toujours est-il que l'étude cible en particulier les domaines des nouvelles technologies.

[ddv]

Nous ne sommes pas à Madagascar; aujourd'hui, la France forme 35000 ingénieurs par an.

Non on forme des généralistes qui sont moyens à tout et bons à rien, pas des ingénieurs. Et c'est bien le problème. Quand tu vois des soit disant "ingénieurs informaticiens" diplomés qui ne sont pas capable de te sortir une requête SQL ou de te pondre un algo basique, tu comprend que le problème n'est pas le diplome mais l'enseignement qu'ont les gens. Et à ce stade la formation de "gestion de projet" ne fait pas la différence.

C'est justement le principe de l'ingénieur, d'être plutôt généraliste: avoir une culture intellectuelle étendue qui permet de s'adapter à tout environnement. On n'attend pas d'un ingénieur qu'il sache écrire une requête sql. On peut attendre cela d'un "pisseur de code" qui fait ça toute la journée.

[fabriceb]

Idem pour les requêtes SQL : il se trouve que, durant deux ans, j'ai bossé dans l'info de gestion. Je ne savais absolument pas ce qu'est une requête SQL en arrivant dans mon nouveau service.

Très sincèrement, tu vas bricoler comme 90% des ingé qui "jouent" avec les SGBD, quand c'est pas le middleware qui pousse à la faute. Genre EntityFramework & co c'est sympa sur le papier, et en premier avis ça paraît tip-top. Enfin c'est tant que tu n'actives pas les dumps système pour y lire les requêtes exécutées et t'apercevoir que c'est Berlin! Franchement, un technique qui s'y connaît vraiment va te dire comment concevoir ton schéma, le vues, les types, index, procédures stockées, triggers et bien entendu les requêtes exécutées par le programme. Il va te dire comment optimiser les traitements qui te sont propres ou éviter certains écueils bien gênants à terme. Je t'accorde quand dans 80% des cas, tu n'as pas besoin d'optimisation car pas assez de données et/ou pas assez complexes et que la sous-optimisation ne se voit pas. Enfin ça c'est si ton système n'évolue pas.

+1

Au début ça marche. Puis les temps de traitements s'allongent : on pallie avec des serveurs plus costaud. In fine ça ne suffit pas. Et là on regarde les requêtes, les index,... Et pour quelqu'un qui connaît on divise les temps de traitement. Expérience Perso on est arrivé dans certain cas à diviser par 4-5 le temps de traitement en réorganisant les requêtes et la structure du sgbd. (11h avant, 2h après).

Ou une base de donnée, non temps réel, Oracle, qui doit tourner en quasi temps réel (moins de 150ms, temps de traitement du programme inclus, avec quelques millions de tupple), là, on doit bien réfléchir aux index, et surtout, bien mettre les outils administrateurs pour vérifier comment le système parcourt les tables (les requêtes en like , que du bonheur en perf pourries, le " qui manquent, ...), après on a l'optimisation des disques durs, du kernel unix, ...
Après non, cela ne s'apprend pas à l'école, car entre un modélisation du SGBD pour k7vidéo, et une base clientèle de taxation temps réel, c'est la même chose en très diffèrent .

+1
Tous les "spécialistes" ont l'air de s'imaginer que leur spécialité s'apprend à l'école et dépend de leur formation ...
Ca s'apprend par la pratique, et quelle que soit ta formation initiale; la formation initiale, ca donne les bases et puis, après, il y a surtout énormément de pratique.
Les subtilités, il faut du temps; cela étant, j'ai vite appris aussi que le vrai critère pour les maitriser, ce n'est pas de savoir si tu as eu une formation de "spécialiste", c'est de savoir si tu en as besoin ... et là, tu acquiers ce dont tu as besoin (normalement ... parce que tu as toujours des gars qui ne veulent pas se donner la peine non plus).
Tu y arrives forcément en te posant la question : "comment ca se fait que ca ne marche pas ?", en passant tu temps à galérer pour que ca fonctionne et avec quelque bouquins ou collègues qui t'expliquent (parce que les index et les vues, sur le principe, y'a pas de quoi paniquer nous plus si je me souviens bien) ; ca n'a rien à voir avec l'école et quelque formation de spécialiste que ce soit.

En ce qui concerne l'info de gestion, je n'en ai fait que 2 ans et j'ai à peine abordé les notions que mentionne slash (la taille des bases faisait que le temps de réponse était un critère moins important que le temps développeur), mais j'ai aussi vu ce qu'il ne fallait pas faire en la matière (un gars faisait une base de données sous EXCEL ... ca permet de sortir un code assez rapidement, mais au bout de 3 ans, les mises à jour quotidienne prenait 15 heures).

Mais la réflexion est la même pour tout type d'algo, et de métier : en calcul des structures, l'optimistation de l'algo peut diviser les temps de calcul par 5, ca n'a rien d'extraordinaire, et ca ne s'apprend pas à l'école : on ne nait pas "technique qui s'y connait".

[franckyfranck]

Non quand je recrute je ne me dis jamais que le mec sera immédiatement opé tout simplement car aucune école n'apprend ce que l'on fait et qu'il n'y aurait pas de marché pour.

Par contre si le mec sais déjà les bases (écrire des algos, savoir coder, et faire un peu de bases de données sont ces bases) je peux lui apprendre des choses et espérer qu'il soit opérationnel en quelques mois. En réalité il mettra plusieurs années à devenir réelement expert sur le sujet. (Soit en télécom soit en video dans mon équipe) et au bout de 10 ans il pourra se faire une double expertise. Un généraliste chez nous il a deux casquettes pas plus

L'informatique c'est vachement vaste donc ok que le mec ne connaisse rien aux spécificités des saltimbanques que nous sommes je prends... Car à moins de se servir chez un concurrent et bien il ne connaitra pas. (Et qu'il y en a moins de 5 en France). Mais les bases (l'informatique) ca il est censé connaitre. Je peux pas à la fois lui apprendre à coder et de l'autre lui apprendre toutes les spécificités techniques d'un serveur vidéo pour l'événementiel c'est juste mort. Donc le mec doit savoir coder quand il arrives et le reste il apprendra (ou pas). Déjà rien qu'apprendre à gérer les contraintes de latence quand tu arrives c'est du boulot si tu sais déjà coder. Si tu ne sais pas coder c'est mort.

[RoyBatty]

Idem pour les requêtes SQL : il se trouve que, durant deux ans, j'ai bossé dans l'info de gestion. Je ne savais absolument pas ce qu'est une requête SQL en arrivant dans mon nouveau service.

Très sincèrement, tu vas bricoler comme 90% des ingé qui "jouent" avec les SGBD, quand c'est pas le middleware qui pousse à la faute. Genre EntityFramework & co c'est sympa sur le papier, et en premier avis ça paraît tip-top. Enfin c'est tant que tu n'actives pas les dumps système pour y lire les requêtes exécutées et t'apercevoir que c'est Berlin! Franchement, un technique qui s'y connaît vraiment va te dire comment concevoir ton schéma, le vues, les types, index, procédures stockées, triggers et bien entendu les requêtes exécutées par le programme. Il va te dire comment optimiser les traitements qui te sont propres ou éviter certains écueils bien gênants à terme. Je t'accorde quand dans 80% des cas, tu n'as pas besoin d'optimisation car pas assez de données et/ou pas assez complexes et que la sous-optimisation ne se voit pas. Enfin ça c'est si ton système n'évolue pas.

+1

Au début ça marche. Puis les temps de traitements s'allongent : on pallie avec des serveurs plus costaud. In fine ça ne suffit pas. Et là on regarde les requêtes, les index,... Et pour quelqu'un qui connaît on divise les temps de traitement. Expérience Perso on est arrivé dans certain cas à diviser par 4-5 le temps de traitement en réorganisant les requêtes et la structure du sgbd. (11h avant, 2h après).

Ou une base de donnée, non temps réel, Oracle, qui doit tourner en quasi temps réel (moins de 150ms, temps de traitement du programme inclus, avec quelques millions de tupple), là, on doit bien réfléchir aux index, et surtout, bien mettre les outils administrateurs pour vérifier comment le système parcourt les tables (les requêtes en like , que du bonheur en perf pourries, le " qui manquent, ...), après on a l'optimisation des disques durs, du kernel unix, ...
Après non, cela ne s'apprend pas à l'école, car entre un modélisation du SGBD pour k7vidéo, et une base clientèle de taxation temps réel, c'est la même chose en très diffèrent .

Je n'allais même pas jusque là. Rien que les requêtes pourries avec des jointures entre tables utilisant des chaînes de caractères comme clef, des likes dans tous les sens, ...

[RoyBatty]

+1
Tous les "spécialistes" ont l'air de s'imaginer que leur spécialité s'apprend à l'école et dépend de leur formation ...
Ca s'apprend par la pratique, et quelle que soit ta formation initiale; la formation initiale, ca donne les bases et puis, après, il y a surtout énormément de pratique.
Les subtilités, il faut du temps; cela étant, j'ai vite appris aussi que le vrai critère pour les maitriser, ce n'est pas de savoir si tu as eu une formation de "spécialiste", c'est de savoir si tu en as besoin ... et là, tu acquiers ce dont tu as besoin (normalement ... parce que tu as toujours des gars qui ne veulent pas se donner la peine non plus).
Tu y arrives forcément en te posant la question : "comment ca se fait que ca ne marche pas ?", en passant tu temps à galérer pour que ca fonctionne et avec quelque bouquins ou collègues qui t'expliquent (parce que les index et les vues, sur le principe, y'a pas de quoi paniquer nous plus si je me souviens bien) ; ca n'a rien à voir avec l'école et quelque formation de spécialiste que ce soit.

En ce qui concerne l'info de gestion, je n'en ai fait que 2 ans et j'ai à peine abordé les notions que mentionne slash (la taille des bases faisait que le temps de réponse était un critère moins important que le temps développeur), mais j'ai aussi vu ce qu'il ne fallait pas faire en la matière (un gars faisait une base de données sous EXCEL ... ca permet de sortir un code assez rapidement, mais au bout de 3 ans, les mises à jour quotidienne prenait 15 heures).

Mais la réflexion est la même pour tout type d'algo, et de métier : en calcul des structures, l'optimistation de l'algo peut diviser les temps de calcul par 5, ca n'a rien d'extraordinaire, et ca ne s'apprend pas à l'école : on ne nait pas "technique qui s'y connait".

Oui bien évidemment, mais aujourd'hui je constate que même des dev avec plusieurs années d'expérience n'ont plus ce recul. On utilise le dernier framework machin, la dernière dB no sql bidule parce que sql c'est compliqué et lent. Résultat des usines à gaz, des coups de maintenance qui explosent (le consultant extérieur 6000 la semaine), des délais de livraison qui doublent (voir triplent mais paraît que c'est agile...). A l'arrivée un mille feuilles lourd dont je m'avance à penser qu'il ne sera pas pérenne très longtemps.

L'ancien système plein de sql : il lui survivra j'en suis persuadé et ce malgré le mépris des développeurs "nouvelle génération" qui prétendaient le réécrire en 2 ans en 2012. Aujourd'hui leur nouveau système s'appuie dessus pour tout ce qui n'est pas la couche présentation... soit tout le cœur métier...

[franckyfranck]

On utilise le dernier framework machin, la dernière dB no sql bidule parce que sql c'est compliqué et lent.

Le pire étant quand cela vient masquer une abscence de base solides. Cas classique en entretien :
- Code moi un tri.
- java.sort(myArray) (ou dans un autre langage, mais souvent ce sont des codeurs java qui me font le coup).
- Non j'ai dit CODES le tri.
- ...

Et bien la c'est pareil on commence à voir des gens qui ont appris direct avec un ORM (type Doctrine ou autre) et qui ne savent pas faire de SQL. Bien sur il est super difficile de leur dire comment utiliser l'ORM correctement. Pire quand l'ORM fait de la 'Mot2Cambronne' (ca arrives plus souvent qu'on ne le voudrait) ils ne peuvent plus lire le SQL pondu derrière par l'ORM et utiliser cela pour comprendre ce qui 'Mot2Cambronne'.

Idem niveau système et réseau ou le DevOps a du bon mais devient de plus en plus une béquille qui aide à ne plus se poser les bonnes questions. Je ne parles même pas de Docker (en soit j'ai rien contre) qui est souvent super mal maitrisé et donne des désastres. Le problème étant la qu'on t'enseigne : Ah ben c'est super, t'as plus à savoir réparer le système quand il 'Mot2Cambronne', tu rebuilde le container et tu le relances. Le jour ou cela ne suffit pas c'est triste.

Le problème est donc souvent que les bases ne sont pas maitrisées. Un mec qui sait coder en C, même si on recrute pour un profil Python va être pris si il nous écrit correctement ses algos en C. Et il est arrivé un jour un mec codant en CAML pour un poste C. Il fut pris et ce fut un bon recrutement Même sur les algos, on ne va pas demander des algos de traitement du signal sauf si on recrute explicitement un signaleux. (Et la il sera interrogé sur les Maths du signal par un gros bourrin de chez nous mais il aura le droit de répondre avec Matlab).

Mais globalement non on ne recrute pas un mec "opérationnel" car un mec opérationnel c'est celui qui sait garantir une latence inférieure à 100ms sur son traitement vidéo (ca fait 3 trames) et qui sait garantir que cette latence va rester stable. On a aussi des contraintes de fiabilité. Pourquoi 100ms ? Parce que si je filme une chanteuse et que je la projette en fonds de scéne, au dela tu aura une impression de "playback". Pour info, sur un évènement dit en direct à la TV on a souvent une dizaine de secondes de décalage entre le stade et la maison (ca c'est gravement aggravé depuis le passage au numérique). Un mec opérationnel connait les techniques pour faire du code "fiable". Et surtout il existe déjà un tas de produit sur le marché qui font des choses et on ne va pas coder s'il en existe un. Donc un mec opérationnel il connait une palanquée de fournisseurs de gadgets exotiques et connait parfois les fonctions cachées des softs. L'autre jour un gars s'est souvenu d'une fonction cachée dans Smode ben ca a évité un gros dev spécifique.

Donc encore une fois on ne demande que les bases ! Le reste s'apprend sur le tas. On ne connait de toute façon pas d'école qui forme convenablement à tout cela.

Idem sur la partie telecom, je ne vois pas qui forme en France des ingés télécoms déjà opérationnel en sortie d'école (même Telecom Paris ne le fait pas) par contre si l'étudiant sort avec les bases il pourra rapidement monter en gamme dans un environnement opérateur.

[ddv]

On utilise le dernier framework machin, la dernière dB no sql bidule parce que sql c'est compliqué et lent.

Le pire étant quand cela vient masquer une abscence de base solides. Cas classique en entretien :
- Code moi un tri.
- java.sort(myArray) (ou dans un autre langage, mais souvent ce sont des codeurs java qui me font le coup).
- Non j'ai dit CODES le tri.
- ...

Typique le genre de question qui me gave: j'ai codé des algos de tri à l'école, pourquoi j'aurais besoin de prouver, 20 ans plus tard, que je sais coder un truc qui ne se fait pas dans le monde réel, puisque le bon ingénieur sait et DOIT utiliser les briques existantes, plutôt que de réinventer la roue.
La bonne question d'un bon RH serait plutôt: quelle brique logicielle utiliser dans tel langage pour trier d'un type de données ?
Et puis, le futur hypothétique salarié devrait, quant à lui, devrait pouvoir vérifier que son futur chef est qualifié et a les compétences d'un leader: savoir motiver les équipes, donner des objectifs clairs, travailler avec des specs, etc. Il n'y a pas des tests dans ce sens ?

[slash33]

Sauf que voilà la bonne question: qui est suffisamment compétent ET forme dans l'entreprise? L'AFPA? J'ai le droit de rire? Si, si j'insiste. Dans un domaine d'activité qui implique beaucoup de prestataires, fortement spécialisé voir externalisé? Nous sommes dans une société hautement individualiste et votre expertise est votre seule valeur ajoutée dans le monde du travail (hormis votre mobilité et votre savoir être mais qui ne se transmet que difficilement). Vous croyez qu'on forme la concurrence (interne comme externe - et oui deux prestas d'une même boîte sont bel et bien concurrents). Il n'y a bien que les sociétés "utilisatrices" (j'adore ce terme vraiment) qui offrent un semblant de formation pour un besoin ponctuel (genre initiation/maîtrise d'un outil de la boîte sinon ça va pas être terrible). Les formations pointues ça existe, d'ailleurs ça donne souvent lieu à une certification. Mais ça coûte les yeux de la tête sans grande certitude pour l'entreprise qui forme! En Inde, ils faisaient pas 6 mois les gus. A peine formés ils allaient se vendre à la concurrence. Mais bon maintenant c'est l'inverse, si vous ne connaissez pas réellement les produits de la société chez qui vous postulez c'est même pas la peine d'y compter.

Encore plus chaud, qui pour apprendre à sélectionner l'outil adapté au besoin et à la situation? Parce que même si vous êtes une pointure sur le plan technique mais que vous avez fait les mauvais choix, cela ne sauvera guère votre projet.

[aleph-zero]

Encore plus chaud, qui pour apprendre à sélectionner l'outil adapté au besoin et à la situation? Parce que même si vous êtes une pointure sur le plan technique mais que vous avez fait les mauvais choix, cela ne sauvera guère votre projet.

Ce point est résolu depuis longtemps. C'est d'ailleurs pour ça qu'il y a encore un ORACLE 7.43 en production, c'est parce qu'il y a 20 ans un stagiaire avait créé une vue que le DSI n'a pas envie de perdre :

DSI> CREATE VIEW choix_fournisseur AS (SELECT name AS nom_fournisseur, sum(retro_com) AS cadeaux FROM fournisseurs GROUP BY nom_fournisseur ORDER BY cadeaux DESC LIMIT 1);

[RoyBatty]

Typique le genre de question qui me gave: j'ai codé des algos de tri à l'école, pourquoi j'aurais besoin de prouver, 20 ans plus tard, que je sais coder un truc qui ne se fait pas dans le monde réel, puisque le bon ingénieur sait et DOIT utiliser les briques existantes, plutôt que de réinventer la roue.

L'objectif est de vérifier la capacité à créer un algo et à le comprendre. Il n'y a pas des briques pour tout et elles ne sont pas forcément efficace dans le contexte. La politique chez nous depuis 6 ans et de recruter des compétences sur des framework. De moins en moins de sql également. Résultats : perf médiocres et traitements qui durent de plus en plus longtemps. Je viens de découvrir qu' une transaction bloquante durait... 1mn30...

Clairement un problème de prise de recul du dev... mais bon il sait manipuler le framework machin...

La bonne question d'un bon RH serait plutôt: quelle brique logicielle utiliser dans tel langage pour trier d'un type de données ?

Et si la brique n'existe pas ?

Et puis, le futur hypothétique salarié devrait, quant à lui, devrait pouvoir vérifier que son futur chef est qualifié et a les compétences d'un leader: savoir motiver les équipes, donner des objectifs clairs, travailler avec des specs, etc. Il n'y a pas des tests dans ce sens ?

Bref de la comm. Au bout de 6 ans et 6-7 départs on en revient. Moi perso je suis extérieur et bien content de ne plus être dans ce bazard.



Envoyé de mon HUAWEI VNS-L31 en utilisant Tapatalk

[franckyfranck]

Typique le genre de question qui me gave: j'ai codé des algos de tri à l'école, pourquoi j'aurais besoin de prouver, 20 ans plus tard, que je sais coder un truc qui ne se fait pas dans le monde réel, puisque le bon ingénieur sait et DOIT utiliser les briques existantes, plutôt que de réinventer la roue.

Non on recrute un ingénieur, le but est de vérifier qu'il sait résoudre quelques problèmes. Après on va adapter en fonction du profil. Si le mec a l'air bourrin on l'enmerde pas avec un tri on a des problèmes durs en stock (genre problème du sac à dos revisité ou d'autres trucs du genre). Le but effectivement c'est qu'on embauche un mec qui va être capable de résoudre des problèmes. Il y a des cas ou une brique technique existe pour les résoudre auquel cas on s'en sert. Mais il y a beaucoup de cas ou on n'a pas de solution. Et il va falloir coder et pas seulement faire de l'intégration. Si c'est un junior, tu prends quelques algos de base (le tri est un exemple) et tu vois si il sait les écrire sans se vautrer. Tu peux poser quelques questions en fonction de ce qu'il aura pondu pour voir si il sait prendre du recul.

Et puis il y a aussi les cas ou les gens ne savent PAS ce que fait la bibliothèque qu'ils appellent en arrière plan. Genre tu as une boucle qui lit un truc sur l'entrée standard et la regexp est compilé dans la boucle (vu pas plus tard qu'hier). Plein d'erreurs sont avant tout du à cela. Qu'on ne réinvente pas la roue c'est ok mais qu'on n'ait aucune idée de ce qui se passe derrière la roue en est une autre. Les framework c'est terrible à ce niveau car souvent le bizuth n'a aucune idée de ce qui se passe derrière quand il tape une ligne de code. Du coup deux solutions ne se distinguent à ses yeux que par leur niveau de verbosité. Effectivement il n'a pas la compétence pour avoir la moindre idée de ce qui se passe derrière. Et dans la plupart des cas, si on interrogeait les gens sur les design patterns qui sont derrière ces frameworks on aurait VRAIMENT du mal à recruter. J'ai quelques questions issues du Gang of Four, je suis rarement satisfait du résultat. Disons le clairement la plupart des gens n'ont aucune foutre idée du fonctionnement interne de Symfony (pour en prendre un à la mode) ou Struts (pour en prendre un bien pourri) mais coderont pourtant avec et pesteront sur le résultat.

Idem d'ailleurs pour le SGBD vu comme le truc magique auquel tu pose une question et qui te donne une réponse (c'est le djinn) mais pas du tout comme un processus qui va prendre plus ou moins de temps selon la manière dont tu lui pose la question.

Sur la partie du leadership il n'est pas interdit de poser des questions sur la manière de travailler dans la boutique. J'y réponds toujours honnétement à savoir : "On bosse avec des saltimbanques, c'est le bordel. L'avantage est que tu va bosser sur des trucs intéréssants techniquement et que tu sera fier du résultat. Mais si tu cherches un environnement normé ou tout est clair, passes ton chemin". C'est extrème dans l'évènementiel effectivement MAIS c'est souvent le cas partout. Les seuls potes que j'ai vu bosser dans des environnements "carrés" c'est dans le militaire, l'aéronautique ou tout secteur qui ne supporte pas l'improvisation. Partout ailleurs l'imprévu fait partie du job.

Cela dit en tant que junior je ne posais jamais cette question mais plutot "sur quels trucs intéréssant je vais bosser, qu'est ce que je vais apprendre".

[moinsdewatt]

La pénurie de compétences menace la croissance en France

Usine Nouvelle le 15/05/2018

Une PME sur deux signale des difficultés à recruter, selon le baromètre publié par Bpifrance et Coe-Rexecode.


L’économie française continue à créer des emplois. Au premier trimestre, elle a encore engrangé 57 900 créations nettes, selon l’Insee. Mais la pénurie de compétences risque de peser sur la croissance rapidement.

Selon le baromètre trimestriel réalisé par Bpifrance et Coe-Rexecode, 52 % des PME signalent que leurs difficultés à recruter constituent leur principal frein à leur croissance, loin devant la concurrence accrue ou le manque de débouché.

..............

https://www.usinenouvelle.com/editorial ... ce.N693734

[Parsifal]

C'est toujours le même problème : pénurie de profils intéressant à pas cher.

Edit : ceci dit je pense que c'est accentué par le fait que les taxes sur les revenus et en particulier les salaires poussent fortement les jeunes à haut revenu à s'exiler.

[stchong]

Un article pour ne rien dire . Manque de quoi ces PME ???? Deplus si elles sont au fin fond du trop du c-u-l de la campagne française tu m'étonnes.

[ddv]

Un article pour ne rien dire . Manque de quoi ces PME ???? Deplus si elles sont au fin fond du trop du c-u-l de la campagne française tu m'étonnes.

J'aurais tendance à dire le contraire: ma boîte peine à recruter en plein coeur de Paris et il est de notoriété que les salaires proposés y sont trop faibles par rapport aux contraintes liés au logement/déplacement dans la ville de Paris.
La moitié de ceux qui s'en vont partent en province (Lille, Mayenne, Nantes, etc.). Comme quoi...

[kamoulox]

Un article pour ne rien dire . Manque de quoi ces PME ???? Deplus si elles sont au fin fond du trop du c-u-l de la campagne française tu m'étonnes.

J'aurais tendance à dire le contraire: ma boîte peine à recruter en plein coeur de Paris et il est de notoriété que les salaires proposés y sont trop faibles par rapport aux contraintes liés au logement/déplacement dans la ville de Paris.
La moitié de ceux qui s'en vont partent en province (Lille, Mayenne, Nantes, etc.). Comme quoi...

+1

Mon père gère sap depuis longtemps , on lui proposait meme pas 50000 bruts à paris
Finalement il a eu encore moins , mais c’était à bordeaux donc il s’est barré là bas pour la qualité de vie. Il remplace un mec parti. Pas de diplômes particulier, juste son XP.
Consultant sap avec +de 20 ans d’XP je pensais que sa tapait très haut. Bien plus en tout cas.

Moi j’ai postulé en étant en veille, j’ai été pris j’ai quitté mon poste auquel j’avais évolué juste avant...
Remplace un gars parti sur paname pour une évolution ailleurs. Je suis plus que certainement celui qui gagne le moins (mais c’est déjà bien à mon niveau)

J’ai quand même l’impression qu’on essaye de recruter au rabais à l’échelon inférieur pour payer bien moins cher en espérant que tu sois opérationnel le plus vite possible , encadré par des mecs d’XP.

Bon je vais pas me plaindre si le marché s’ouvre ainsi ça m’arrange. J’ai quand même l’impression qu’il y a bien plus d’opportunités qu’en 2016 par exemple (pour des gars comme moi j’entends )

[cashisking]

C'est toujours le même problème : pénurie de profils intéressant à pas cher.

Je vois plutôt les choses comme ça : Quand t'es en poste avec un salaire déjà correct, tu hésites à changer car le marché du travail en France est ultra rigide (3 mois de préavis puis 8 mois de période d'essai, en gros une année de transition, avec un risque non nul de se faire planter par le nouvel employeur). Et pour que les gens soient prêts à prendre ce risque de changement, il faut une grosse augmentation. Problème : Quand tu prends 10k€ bruts par an, il t'en reste 5k€ dans la poche après taxes et impôts.
Bref, il y a une belle prime à l'immobilisme dans le pays.

[Pi-r2]

oui enfin, je regarde les offres d'emploi et c'est assez pauvres. On en est pas encore à se faire démarcher à domicile hein.
Ils cherchent la compétence EXACTE pour rentrer tout de suite dans leur case et être opérationnel immédiatement (tout ça payé au lance pierre), tu m'étonne qu'ils trouvent pas

[Gpzzzz]

C'est toujours le même problème : pénurie de profils intéressant à pas cher.

Je vois plutôt les choses comme ça : Quand t'es en poste avec un salaire déjà correct, tu hésites à changer car le marché du travail en France est ultra rigide (3 mois de préavis puis 8 mois de période d'essai, en gros une année de transition, avec un risque non nul de se faire planter par le nouvel employeur). Et pour que les gens soient prêts à prendre ce risque de changement, il faut une grosse augmentation. Problème : Quand tu prends 10k€ bruts par an, il t'en reste 5k€ dans la poche après taxes et impôts.
Bref, il y a une belle prime à l'immobilisme dans le pays.

De surcroît tu sais ce que tu quittes et tu ne sais pas ce que tu retrouves..
si tu changes pour gagner 400 balles net par mois en plus, disons entre 10 et 15% d augmentation, mais que tu dois travailler 9h plutôt que 7h30 a la fin tu gagnes rien en salaire horaire..

autour de moi les gens qui ont changé de boîte récemment, ils ont eu une augmentation de salaire intéressante mais ils ont bougé car leur situation n était plus vivable... Soit il se tapait déjà des journées de 9/10h depuis des années sans vraiment être récompensé, soit il y avait une ambiance de 'Mot2Cambronne' au boulot, soit ils avaient un N+1 qui leur cassait les noix.
Bref c est peut être plus ca la raison principale d un changement de boîte..

[cashisking]

De surcroît tu sais ce que tu quittes et tu ne sais pas ce que tu retrouves..
si tu changes pour gagner 400 balles net par mois en plus, disons entre 10 et 15% d augmentation, mais que tu dois travailler 9h plutôt que 7h30 a la fin tu gagnes rien en salaire horaire.

C'est toujours ma plus grosse crainte

[aleph-zero]

Ils cherchent laes compétences EXACTES pour rentrer tout de suite dans leur case et être opérationnel immédiatement (tout ça payé au lance pierre), tu m'étonne qu'ils trouvent pas

Et "parler couramment le Chinois ainsi que la connaissance du processus de conservation des petits pois seraient des plus".

[Suricate]

C'est toujours le même problème : pénurie de profils intéressant à pas cher.

Je vois plutôt les choses comme ça : Quand t'es en poste avec un salaire déjà correct, tu hésites à changer car le marché du travail en France est ultra rigide (3 mois de préavis puis 8 mois de période d'essai, en gros une année de transition, avec un risque non nul de se faire planter par le nouvel employeur). Et pour que les gens soient prêts à prendre ce risque de changement, il faut une grosse augmentation. Problème : Quand tu prends 10k€ bruts par an, il t'en reste 5k€ dans la poche après taxes et impôts.
Bref, il y a une belle prime à l'immobilisme dans le pays.

Moi j'ai choisi de bouger : gagner moins qu'avant mais avec une qualité de vie supérieure. Des journées plus longues au boulot mais moins de temps passé dans les transports. Et puis dans un grand centre urbain 70m² à 4 ça devenait compliqué, 120m² c'est mieux.

Le temps où je courrai comme un lapin pour taper un TMI à 41% est révolu. Désormais nous sommes non imposables (temporairement) et on vit pourtant mieux (en faisant un peu attention quand même), on envisage même d'acheter, c'est dire.

[kamoulox]

La qualité de vie ça n’a pas de prix

Tu es dans quel coin du coup ?

[Suricate]

Saumur, Maine et Loire.

[kamoulox]

A oui c’est vrai! Tu as bien fais, profite!

[alexlyon]

Dialogue de sourd.
C'est parce que le marché du travail ne devrait pas être un marché.
C'est une affaire humaine, pas une marchandise.

Dialogue de sourd parce que :
le salarié ne trouve pas d'offre assez viable pour lui (rémunération de sa prise de risque).
l'entrepreneur ne trouve pas de Mozart au smic.

Se plaindre que la contrepartie est décevante parce qu'absente, c'est juste être hors marché (ce ne sont pas les gens qui manquent, mais la capacité à se remettre en question, notamment chez les employeurs).

Après ce qui est fondé, c'est que la mondialisation impose des benchmarks et des repères indiscutables. Et douloureux.

Cela n'a pas de sens de payer davantage à l'heure l'ouvrier français que le japonais ou le coréen.
La clé pour les masses, c'est le protectionnisme qui, comme son nom l'indique et contrairement à la propagande...protège.

[Tom-Personne]

Le problème, c'est que le monde de l'entreprise est bien trop profondément imprégné par l'idéologie des "ressources humaines".

Evidemment, une entreprise ne peut pas vraiment faire autre chose que rationnaliser le travail et le "profil" de ses salariés, d'autant plus quand ils sont nombreux.
Mais dans la vraie vie, bien entendu, ça ne fonctionne pas comme ça.
L'humain est toujours trop rétif, et ne se "gère" pas comme des ressources financières ou matérielles.

Faute de suffisamment prendre en compte cette réalité, les entreprises se retrouvent toutes en compétition sur le même marché aux esclaves salariés, pour trouver le meilleur profil au meilleur prix, de préférence qui aura déjà été formé par le concurrent.
Sauf qu'au final, la notion de métier finit par complètement disparaître, parce qu'elles cherchent à externaliser l'apprentissage de leurs salariés.

D'où la pression sur le système éducatif pour former les étudiants aux besoins du marché du travail, alors que ce n'est pas du tout sa raison d'être.
D'où aussi la montée concomitante du self-marketing... et de l'incompétence...