Recrutement IT : Comment rédiger la plus cool des fiches de poste ?

Le marché du recrutement, dans l’informatique, atteint des records depuis 2021. Cette année, 69%[1] des entreprises françaises envisagent de recruter de nouvelles compétences informatiques, avec notamment des besoins de plus en plus importants chez les PME et ETI.

[1] Source : Usine Nouvelle

Malgré cette hausse des besoins de recrutement IT, 70% des entreprises admettent rencontrer des difficultés à recruter, et ce, pour des raisons multiples :

  • Des candidatures qui ne correspondent pas aux attentes ;
  • Une baisse des candidatures ;
  • Des recrues plus exigeantes, qui ne craignent plus la « démission » ;
  • Un vivier de candidats trop limités…et des difficultés à élargir ce vivier vers des recrues plus « atypiques » …
Nous pouvons compléter cela par les retours d’expérience de nos équipes techniques. Chez Cool IT, nous travaillons régulièrement avec des informaticien•nes indépendant•es, qui ont opté pour ce statut, à défaut d’avoir déniché des opportunités, en phase avec leurs perspectives et valeurs.

À force d’être plus ou moins bien démarchés, plus ou moins bien intégrés, elleux ont accumulé un ensemble de « Red Flag », des signaux d’alertes, communiqués largement dans les communautés de développeur•ses :

  • Le manque d’équilibre entre vie pro et vie personnelle ;
  • Les dettes techniques trop importantes ;
  • Les projets hors périmètre ;
  • Les organisations trop cloisonnées (les Tech d’un côté, le Métier de l’autre) ;
  • Le refus catégorique de mettre en place du travail hybride ;
  • Le manque de transparence des rémunérations ;
  • Le peu de temps accordé à la formation, la veille et l’auto-formation…

Mais comment ces personnes arrivent-elles à desceller ces informations, avant même d’avoir intégré l’entreprise ? La réponse…Dès la lecture de la fiche de poste ! En effet, votre fiche de poste peut en dire beaucoup sur les conditions dans lesquelles vos futur•e•s développeur•ses vont évoluer.

Dans cet article, vous trouverez un ensemble de question et de conseils pour réaliser une fiche de poste ciblée et cohérente, et ce, grâce aux étapes suivantes :
  • Valider que c'est bien d'un•e dév dont vous avez besoin ;
  • Cadrer les projets que vous allez lui confier à court, moyen, long-terme ;
  • Définir une promesse claire et réalisable (et un salaire juste) ;
  • Anticiper un parcours de carrière ;
  • Déconstruire vos biais et vos clichés sur les développeur•ses

#1 — Valider que c'est bien un•e dév qu'il vous faut

Les questions à se poser

  • Est-ce que mon besoin fait appel à de la programmation informatique ?
  • Est-ce que je connais les différents types de profil dont j'ai besoin ?
  • Est-ce que je connais les langages de programmation utilisés dans mon entreprise ? À quoi ils servent ? Les personnes qui en sont à l’initiative ?
  • Est-ce que j'ai besoin de compétences en plus de la programmation (gestion de projet, graphisme, sécurité...) ?
  • Ces compétences en plus, correspondent-elles aux compétences de base d'un•e développeur•se ?
  • Ces compétences en plus, sont-elles des savoir-faire ou des savoir-être ?

Pourquoi ces questions ?

L’informatique et les métiers du Digital (plus axés créativité et communication-marketing) regroupent un ensemble de compétences numériques, qui peuvent paraître semblables.

Questionner vos connaissances de ces métiers, vous aidera à confirmer si vous avez besoin d’une personne qui maîtrise la programmation informatique, d’une personne qui intègre du contenu, ou d’une personne qui administre des contenus.

Sans être expert, connaître les bases d’un métier permet d’éviter les écarts entre la fiche de poste, les entretiens que vous allez mener et la réalité du terrain. Programmer, c’est une compétence technique, si ce que vous proposez n’est pas de la programmation, on va vite s’en rendre compte.

En revanche, bons nombres de développeur•ses peuvent avoir des compétences transverses : gestion de projet, graphisme, sécurité, data management…Ces compétences ne sont pas obligatoires dans les cursus de dév, et varient en fonction des parcours (en école, en reconversion, en autodidacte…)

#2 — Réfléchir en amont aux projets qui vont être confiés

Les questions à se poser

  • Combien de projet avez-vous à confier à la future recrue ?
  • Avez-vous déjà eu à travailler avec un•e dév avant ?
  • Qui sont les personnes avec qui la future recrue va travailler ? Travaillent-elles en présentiel ? Distanciel ? Quels sont leurs rôles ? Peuvent-elles encadrer la nouvelle recrue ? Ou inversement ? Ont-elles besoin d’être encadrées ?
  • Quelles sont les technologies et les outils associés à chacun de ces projets ? Sont-ils suffisants ? Sont-ils à jour ? Avez-vous des manques ?
  • Quels sont les délais de ces projets ? À quels stades d'avancée sont-ils ? Leurs objectifs ?
  • Ces projets sont-ils réalisables à distance ? Qu’est-ce qui doit être réalisé en présentiel ? Qu’est-ce qui ne nécessite pas une présence physique ?
  • Avez-vous suffisamment de projet pour un CDD ? Un CDI ? Du temps partiel ? Du temps plein ?

Pourquoi ces questions ?

Après avoir validé qu’il s’agit bien d’un•e développeur•se qu’il vous faut, reste à savoir si vous avez suffisamment de travail à lui donner, mais pas que…Ces questions vont aussi vous aider à évaluer votre environnement technique, et son organisation.

Les acquis et les manques que vous aurez identifiés vous permettront de formaliser :

  • Les technologies et/ou la logique de programmation que la recrue devra connaître ;
  • Les problématiques qu’elle pourrait vous aider à résoudre ;
  • Les compétences relationnelles qu’elle devra développer ;
  • La durée du contrat et les conditions de mobilité ;
  • Son niveau de responsabilité…

#3 — Définir une promesse claire et réalisable

Les questions à se poser

  • Le salaire envisagé est-il juste par rapport aux niveaux de responsabilités, et aux tâches qui seront confiées ?
  • Est-ce que mon entreprise a la capacité de faire évoluer la nouvelle recrue ? En termes de compétences ? De poste ? De salaire ?
  • Quelles sont les valeurs de mon entreprise ? Quelle est sa culture ?
  • Quel type d'organisation mon entreprise est-elle en mesure de mettre en place ? Sur quoi peut-on évoluer ? Sur quoi est-elle figée ?
  • Quelle va être la place de la future recrue dans l'entreprise ? Son rôle ? Le sens de ses missions ?

Pourquoi ces questions ?

La promesse qui découle d’un poste peut être décisive pour un•e candidat•e. En effet, des valeurs fortes, des missions qui ont du sens, peuvent contrebalancer des projets peu « sexy », ou une proposition de salaire un peu basse…Surtout pour les métiers techniques, où les salaires sont très attractifs.

Le sujet du salaire est aussi primordial car, si votre politique de salaire est transparente, votre culture d’entreprise peut être perçue tout comme.

Il en va de même pour les questions de valeur, de sens et d’accompagnement de la recrue. Intégrer une nouvelle personne, c’est intégrer son vécu, et le recul qu’elle pourrait avoir sur votre entreprise.

Il y aura des profils qui s’adapteront complètement à votre organisation, et n’y verront rien à améliorer. D’autres auront des idées, des divergences…mais, en fonction de vos objectifs d’innovation, est-ce vraiment une si mauvaise chose ?

#4 — Définir un parcours de carrière challengeant

Ce dont vous devez tenir compte

  • Les développeur•ses ont besoin de temps dédié à la veille, la structuration de leurs idées, la formation ou l'auto-formation ;
  • Il y a des profils qui souhaiteront gagner en responsabilité, d'autres sont davantage motivés par l’exécution ;
  • Il y a des profils qui voudront voir évoluer leurs réalisations de bout en bout, d’autres juste leur périmètre d’activité ;
  • Il y a des profils qui se satisferont complètement des technologies de l’entreprise (même si elles sont vieillissantes), et d’autres vous accompagneront à rester à l’écoute des tendances, voire être plus avant-gardiste ;
  • Il y a des profils qui souhaiteront rester touche à tout, d'autres souhaiteront se spécialiser (dans la data, l’IA, l'architecture, la sécurité...) ;
  • Il y a des profils qui sont entrepreneur•e dans l'âme, et qui développeront des projets en dehors de l'entreprise (qui peuvent vous servir, ou non) …

Pourquoi en tenir compte ?

Savoir ce qui motive, et maintient la motivation, vous permettra d’anticiper les parcours de carrière et les formations qu’un•e développeur•se pourraient suivre. Savoir que les technologies évoluent aussi vite que les aspirations, vous évitera d’être pris de cours.

Si vous n’avez pas d’idées très claires des perspectives d’évolutions, que vous pourriez proposer à un•e développeur•se, n’hésitez pas à poser la question à celleux avec qui vous travailler déjà. Et si c’est la première fois que vous recrutez ce type de profil, posez la question à des communautés de dév. Quitte à poser la question en entretien !

#5 - Il faut sortir des clichés du geek blanc à capuche !

  • Un développeur, est aussi "une développeuse" ou "un•e développeur•se", avec des origines ethniques diverses
  • Les parcours de dév sont multiples : en grandes écoles, en université, en reconversion, en auto-didacte...
  • C'est un métier tout à fait adapté aux personnes handi, et aux personnes neuro-atypiques
  • L'informatique ça bouge, et ça bouge vite ! Un•e Junior peut autant apporter qu'un•e Senior. Faire collaborer les 2, c'est encore mieux !
  • Junior, ça veut dire "Débutant" pas forcément "Jeune"
  • Senior ça veut dire "Expérimenté", pas forcément "Âgé"
  • Dév, ce n'est pas obligatoirement un travail solo. On peut aussi coder à plusieurs !

Pourquoi en tenir compte ?

Il n’y a pas qu’une « pénurie » de talents. Il y a aussi des talents mis de côté. Mis de côté, parce que nous avons tous des idées préconçues de ce à quoi doit ressembler un•e développeur•se. Et effectivemement, ces idées, ces clichés, sont en pénurie.

En moyenne, les entreprises, qui ont pris le parti de déconstruire le recrutement, pour diversifier leurs équipes techniques, sont 15% à 35%[1] plus performantes financièrement et attractives. Renverser les statuts quo du recrutement IT, n’est pas qu’un enjeu sociétal, c’est aussi un enjeu de développement économique.

[1] McKinsey Diveristy Database « Why diversity matters? »

Pour aller plus loin

Télécharger notre Cool Kit de recrutement

Modèle de fiche de poste gratuit

Découvrez notre interview de Marcy Ericka Charollois
Consultante Inclusion et créatrice de contenus Social Tech


À quoi sert un Ingénieur en Système d'Information ?

L’ingénieur en Système d'Information (SI) fait partie de la catégorie « Ingénieur informatique », dans lequel se retrouve les Ingénieurs Développeurs, Ingénieurs Réseaux et Télécoms, Ingénieur en informatique Industrielle etc.

Son rôle majeur est de piloter le bon fonctionnement du Système d’Information de l’entreprise en assurant la cohérence des projets IT avec celui-ci.

Quel est le rôle de l’Ingénieur SI dans un projet IT ?

Le rôle de l’Ingénieur SI dans un projet IT est d’être garant·e de l’intégration du projet IT dans le fonctionnement du SI. Il/Elle possède une forte capacité d’adaptation et de montées en compétences sur des processus métiers, de nouveaux outils informatiques, de nouveaux langages ou nouvelles tendances… L’Ingénieur SI dispose donc d’un profil généraliste avec une appétence forte pour la remise en question et la veille de tendance technique, à savoir :

- Structurer l’ensemble du portefeuille projets : choix de la solution, phasage, procédures, gouvernance, planning, budget, ressources et moyens… ;

- Identifier et anticiper les risques ;

- Assimiler et traduire les besoins métiers auprès du Service informatique ;

- Préparer les développements informatiques ;

- Anticiper les impacts des projets IT sur le Système d’information ;

- Valider la cohérence des choix IT réalisés par les Services informatiques ;

- Documenter le Système d’information en tenant compte des évolutions techniques ;

- Accompagner le maintien des bonnes pratiques ;

- Garder une vision globale du SI de l’entreprise tout au long du développement de celui-ci ;

- Prévenir et assurer la rationalisation des solutions intégrée au SI.

Qu’est-ce que l’Ingénieur SI ne fait pas ?

Bien que l’Ingénieur SI ait un profil généraliste, il/elle n’est pas censé réaliser toutes les tâches qu’incombent un projet IT telles que :

- La gestion opérationnelle des activités informatiques – Ce poste est celui d’un·e DevOps ou d’un Administrateur. En revanche, l’ingénieur SI peut intervenir sur les besoins des opérationnels telles que l’amélioration des outils de gestion de projet, la conception d’outil de suivi, la définition d’indicateurs, la résolution d’incidents trop récurrents…

- Le développement informatique – Ce poste est celui d’un·e Développeur·se dont les compétences sont spécifiques en fonction des solutions et du langage qu’elles requièrent. L’ingénieur SI doit plutôt intervenir dans le pilotage global d’un projet de développement si celui-ci sollicite le Système d’information

- L’administration et le paramétrage d’outils - Ce poste est celui d’un·e administrateur·rice. L’Ingénieur intervient davantage en amont pour la cohérence des paramétrages avec les besoins Métier et le bon fonctionnement du SI

Quand doit-on faire appel à un·e Ingénieur SI ?

Il est conseillé d’être accompagné par un·e Ingénieur SI pour chaque projet qui a un impact fort sur le Système d’information, et ce, dès la détection du besoin jusqu’aux premiers mois de mise en place.

Quelle est la différence entre un Ingénieur SI, un Informaticien et un Chef de projet technique ?

Le/La chef de projet technique coordonne la réalisation d’un ou plusieurs projets informatiques, de la formalisation du besoin jusqu’à la mise en production. L’ingénieur SI, quant à lui ou elle, coordonne les sujets des Chefs de projet qui ont un impact sur le Système d’information. Il/elle a une vision globale de l’ensemble des projets IT afin d’assurer le maintien du Système d’information au fil des avancées des différents projets.

Quant à l’Informaticien·ne, il/elle est sollicitée pour réaliser des actions qui nécessitent une expertise technique spécifique : proposer une solution, la développer, l’intégrer et la maintenir. Il/elle peut aussi assurer le support technique pour les utilisateurs. C’est un rôle plus opérationnel que stratégique.