Développeurs : comment trouver une mission qui vous correspond ?

(… et reconnaître les mauvaises du premier coup d’œil)


Bonjour, cet article fait partie d’un lot de 3 articles centrés sur le recrutement des développeurs. Les deux autres articles abordent le thème du recrutement d’un développeur stagiaire et d’un développeur professionnel (non encore publié).

Je suis Camille Khalaghi, ingénieur développeur dans l’informatique depuis plus de 10 ans (aujourd’hui CTO), et je suis assez déçu de l’environnement de recrutement des ingénieurs informaticiens. Je vais vous livrer ici quelques informations, certains points de vue, des avis et des analyses qui ne sont que personnels, basés sur ma modeste expérience, pour vous aider à choisir votre mission.

Qu’est-ce qu’un développeur ? Quels sont les différents profils et leur vision ? Quel type de développeur suis-je ?

Le developpeur-architecte
Le développeur architecte est le profil le plus formé par les écoles. Il a une vision long terme de l’application et son but est de faire les choses bien dès le départ pour minimiser les coûts de maintenance (la maintenance est ce qui vaut le plus cher dans une application).
Il fait les choses une fois et n’a presque plus à revenir dessus après. Il excelle dans le développement d’applications, la refonte ou l’ajout de fonctionnalités dans des environnements constants.
Sa vision : construire des applications pérennes, certes plus chères à l’achat, mais nécessitant le minimum de maintenance (et donc bien moins onéreuses sur des périodes de 2 à 5 ans)… pour ensuite dormir financièrement dessus en faisant des semaines de 8 heures. [C’est un bon plan, hein ? :)] Il est souvent engagé dans son travail et le prend à cœur.

Le developpeur-POC
POC est l’acronyme de « Proof Of Concept » : on lance un concept sur le marché et on voit si ça mord. Un POC est une petite application qu’on lance au plus vite et à coût minimal sur le marché pour voir comment le marché réagit. Le développeur POC est de loin le plus rare. Il a une grande connaissance des modules utilisables existants sur le marché et son but est de reprendre ces modules, de les lier pour en faire une app. et de la lancer sur le marché au plus vite. Les applications POC sorties nécessitent beaucoup de maintenance et ne tiennent pas la charge face à un trop grand nombre d’utilisateurs, mais leur prix de lancement est faible. Le POC fuit devant la maintenance lourde. Sa vision : travailler pour de nombreux clients, créer beaucoup d’app. et aller au plus vite/aller au plus simple. Sur le nombre, peut-être qu’une de ces app. le rendra riche ? Quand l’idée d’une de ces app. rencontre du succès, regroupe beaucoup d’utilisateurs et que l’app. commence à ramer, ne supporte plus la charge, alors on la réécrira en mieux.

Le developpeur-débuggueur
Le débuggueur est le roi de la rustine et des bouts de ficelles. Chargé de la maintenance d’une application, il n’a pas besoin d’avoir un point de vue global sur tout le périmètre de l’application, mais juste sur celui du bug en question. Il est souvent méprisé par les autres profils de développeurs, mais on a besoin de profils comme celui-ci dans une équipe, son rôle est entier. Si un débug produit des effets de bord (un autre bug en cascade dans un autre module de l’application) : pas de soucis : il débugguera ce nouveau bug rapidement, et ainsi de suite.
Il n’est souvent pas très engagé dans son travail, mais il fait ce qu’on attend de lui.
Sa vision : si on lui demande de maintenir une application, c’est qu’elle génère de l’argent ; son but est de faire ce qu’il faut pour qu’elle continue à en rapporter en allant au plus vite/au plus simple.

Le developpeur-chef de projet technique
Le chef de projet technique est un développeur expérimenté capable de piloter un projet et de coordonner les autres développeurs (et autres compétences : intégrateurs, SEO, etc.).
Il intègre en plus de son travail, la vision marché, client et fournisseur, ainsi qu’une vision humaine du management.
N’importe quel type de développeur précédent peut devenir chef de projet technique, mais gardera néanmoins sa vision initiale.

Ainsi, un développeur ne pourrait pas tout faire ?
Les personnes ne sont pas des couteaux suisses, et j’ai beaucoup de doutes sur ceux qui se disent full-stack.
Les architectes, par exemple, peuvent faire du POC, mais pas de maintenance (ça ne colle pas avec leur vision). S’ils peuvent en faire de temps en temps, mettre un architecte sur une mission full-maintenance est une erreur de recrutement, et aboutira très vite à une démotivation et une démission.
Les POC ne peuvent pas avoir des missions d’architecte : un POC a une vision bien trop court terme et se sentira frustré en ne sortant pas assez vite de fonctionnalités. En revanche, il peut faire de la maintenance assez facilement.
Les débuggueurs peuvent faire du POC, mais pas d’architecture : ils ne sont pas engagés et veulent juste maintenir l’existant.

Quand postuler ?

En octobre arrivent tous les jeunes diplômés, et en été tout est ralenti. Les bonnes dates sont de novembre à mai. Pourquoi ne pas faire une petite formation entre 2 jobs si vous n’êtes pas dans la bonne période ?

Sur quel type de mission un développeur peut-il postuler ?

Mission de lancement d’une nouvelle application/logiciel/site Web
Ce produit est-il pérenne ou pas ? Devra-t-il absorber un grand nombre d’utilisateurs ou pas ? Si oui (et c’est rare) : cette mission est faite pour un architecte-chef de projet-CTO. Sinon : pour un POC.
Il faut savoir que dans le cadre d’un POC, si l’application a du succès, elle devra être intégralement réécrite par un architecte dans les 2 à 4 ans maximum. Entre-temps, elle aura besoin d’un profil débuggueur pour la maintenir.

Mission de refonte globale
Quand une app. POC a du succès, son coût de maintenance devient très élevé, et sa vitesse ralentit au fur et à mesure que son nombre d’utilisateurs grandit ; et les utilisateurs deviennent mécontents.
C’est à ce moment-là (et si possible un peu avant) qu’il faut prévoir une refonte globale.
Pour une refonte globale, un profil d’architecte est nécessaire.

Mission de refonte modulaire :
Une refonte modulaire est en général ce que demandent les directions quand les clients deviennent mécontents de la lenteur d’une app. POC. « Une refonte globale coûte trop cher et il faut tout sortir d’un coup. C’est trop demander à nos actionnaires alors on va refondre module par module et étaler dans le temps ».
Si vous êtes un développeur front-end : pas de soucis, les librairies JavaScript en double se côtoieront un bon bout de temps, mais ce n’est pas plus grave que ça.
Le problème de la maintenance modulaire, c’est qu’elle exclut le changement de schéma de la base de données (sinon c’est une refonte globale) ; or c’est souvent là que se situe le cœur du problème de lenteur.
D’expérience, jamais aucune refonte modulaire n’a marché, jamais ! Par contre, elles ont toujours coûté très, très, très cher, bien plus qu’une refonte globale, les résultats sont toujours très limités, et les clients toujours très mécontents.
Si vous êtes un développeur back-end, les refontes modulaires sont d’expérience vouées à l’échec ; c’est une mission sans intérêt dans laquelle il faut mettre beaucoup d’énergie pour rien.
Refusez les missions de refonte modulaires, vous allez systématiquement vous faire réprimander par la direction, qui attend toujours plus de résultats sans jamais vouloir y mettre le moindre moyen.

On veut grossir l’équipe
Les clients qui demandent cela sont soit des clients qui ne savent pas ce qu’ils veulent, soit des clients qui ne veulent pas dire que c’est une mission de débug.
Dans tous les cas, c’est une mission de débug.
Sachez lire entre les lignes : « On est allé trop vite, on a fait trop de “caca” dans le code. On a aujourd’hui tellement de dettes techniques dans l’application qu’on est obligé de grossir l’équipe à contrecœur ou de faire une refonte globale. Comme on ne veut pas faire de refonte et qu’on ne trouve personne pour débugguer le “gros caca”, on est prêt à recruter n’importe qui ! »
Ce type de clients considère l’informatique comme un centre de coût plutôt qu’un centre de production, et ce coût sera donc toujours trop élevé, quelle que soit son efficacité.
Ce type de mission est davantage faite pour un débuggueur, mais est à fuir impérativement.

Mission de débug
C’est le même type de mission cité précédemment, sauf que dans ce cas-là le client a l’honnêteté de dire que c’est une mission de maintien d’une app.
Le travail sera le même, mais l’ambiance sera sûrement plus saine.
Ce type de mission est parfait pour un débuggueur.

Ajout de fonctionnalités sur projet existant
Si c’est un projet POC : POC.
Si c’est un projet pérenne : architecte.
Posez la question : ce projet a-t-il déjà eu sa refonte globale ?

Reprise d’une app.
Traduction : « L’ancien chef a fui/s’est lancé dans un nouveau projet/s’est pendu, et on en recherche un nouveau ».
Ce type de mission sera en général pour un type de développeur POC ou architecte + manager + chef de projet, en tout cas pour quelqu’un de malléable et de très conciliant.
Attention toutefois aux problèmes politiques sous-jacents : un chef n’abandonne jamais son bébé sans raisons graves.

Dans quelle type d’entreprise postuler ?

Les Start-ups jeunes (< 3 ans)
Ces start-ups vont devoir lancer leur produit sur le marché au plus vite. Elles ont besoin de POC-manager-chef de projet (même junior) et de débuggueurs. Freelance si possible.

Start-ups ayant un POC réussi (3-7 ans)
Ces entreprises ont réussi à avoir des clients et leur logiciel commence à ramer. Une refonte globale est à prévoir.
Parfait pour un architecte. Elles peuvent également avoir besoin de débuggueurs.

Start-ups âgées (> 7 ans)
Tous types de développeurs, en particulier architectes et débuggueurs.
Si de nouveaux projets sont prévus, un POC ou un architecte est le bienvenu à la tête de ces nouveaux projets.

Les associations
Pas de budget, pas de visibilité.
Un POC (freelance ou dans une agence) est le bienvenu.

Les éditeurs logiciels
Ces entreprises ont bien saisi qu’il leur faut limiter les coûts, en particulier ceux de maintenance (les éditeurs qui ne comprennent pas cela meurent assez vite). Ils recrutent principalement des architectes, mais aussi quelques débuggueurs.

Les agences Web (boites de comm’)
Ces agences adorent les POC. Elles recrutent aussi quelques débuggueurs. Les projets sont toujours de très court terme.

Institutions privées
Les institutions se moquent bien des profils et des informaticiens, ça ne les intéresse pas. Il leur faut de la « chair à canon ». Il leur faut surtout des débuggueurs, et éventuellement quelques architectes sur les nouveaux projets.

Les institutions publiques
C’est la même chose que pour les institutions privées : beaucoup de débuggueurs, un peu d’architectes.

Les fournisseurs de service
Le système est à peu près le même que pour les éditeurs logiciels. D’où les mêmes conséquences : les fournisseurs de service recherchent principalement des architectes, mais aussi quelques débuggueurs.

Les SSII financières
Elles recrutent tous types de dév. du moment qu’elles peuvent les placer.
Certaines essaient de faire des efforts, mais sont extrêmement rares. Les autres ont très mauvaise réputation.
Chez les SSII financières, un dév. peut très bien en remplacer un autre. Elles ne sont d’ailleurs intéressées que par le placement, quel que soit le client, quel que soit le développeur, quel que soit le projet, quelle que soit la finalité. Atterrissent ici les missions des grands groupes, mais aussi beaucoup de missions « dont personne ne veut ». À vous, en fonction de la mission proposée, de postuler en mode mercenaire ou pas. Ces sociétés sont séduisantes quand on veut trouver un travail assez vite, mais elles sont très « court-termistes » ; et souvent assez malhonnêtes.
Les SSII financières sont de très loin les plus nombreuses sur le marché. Pour les reconnaître, c’est simple : quand vous allez à leur siège, il n’y a que des RH-sourceurs et des commerciaux. Il n’y a pratiquement pas de dév. au siège et c’est ce qui les différencie.
Je vous conseille de contacter les anciens salariés pour différencier le vrai du faux.

Les SSII technologiques
Les SSII technologiques ressemblent davantage à un rassemblement anarchique de développeurs freelances, souhaitant travailler sous une bannière juridiquement officielle, qu’à une société de placement. En général, vous serez reçus par un dév. et un(e) responsable RH.
Tous les types de développeurs peuvent y postuler à condition d’être respectueux, humbles et honnêtes. Travaillant aussi sur des projets au forfait, il y a principalement des développeurs au siège, accompagnés de quelques rarissimes RH, comptables et commerciaux.

Bureaux de recrutement
Même s’ils font davantage de recrutement que de régie, leur vision n’est pas si différente d’une SSII financière. Ils engagent tous les profils, pour tout le monde, sans de réelles distinctions.

Agents personnels de recrutement/agents de freelance
Même si c’est un nouveau métier, ces personnes sont très professionnelles et payées au résultat. Et leurs résultats sont souvent très intéressants.

Comment postuler/se mettre en ligne ?

Réseaux sociaux professionnels : LinkedIn & Viadeo
C’est le moyen le plus simple de se faire connaître, en y mettant son C.V. et en se rendant visible aux robots de recherche, aux entreprises, au recruteurs et chasseurs de tête. À utiliser absolument.

Sites personnels
C’est un moyen simple de se présenter un peu plus en détail que sur LinkedIn.
DoYouBuzz est un moyen assez sympa de mettre son C.V. en ligne sous forme de site personnel, et d’avoir une bonne place dans Google.

Répondre aux annonces sur les jobboards
Les jobboards listant les annonces sont assez cools à utiliser et peuvent vous permettre de répondre et de postuler aux annonces.
Les principaux sont : LesJeudis, RemixJobs, ChooseYourBoss et Monster.

Les sites d’entreprise
Vous avez ciblé une ou plusieurs entreprises ? Leur site comporte presque systématiquement un onglet recrutement. Vous pouvez postuler aux annonces ou faire une candidature spontanée.

Sites spécialisés de talents
Des sites haut de gamme avec des annonces de qualités pour des profils expérimentés sont à la mode.
Leurs noms : talents.io, techtalents.io, adopteuncto.com, Flaiir.io, hired.com, etc.

Agents personnels de recrutement/agents de freelance
Comme dit plus haut, c’est un nouveau métier, et ces personnes sont très professionnelles et payées au résultat. Leurs résultats sont souvent très intéressants. C’est à mon avis la meilleure manière de faire, mais elle n’est pas gratuite.

Quelques conseils supplémentaires

— Les responsables RH demandent parfois d’une liste de compétences longue comme la barbe du père Noël : « Je recherche un dév. junior Star Java, bon JS, modélisation, en Postgres, en NoSQL, XP avec Docker, Hadoop, Machine learning, photoshop et Data mining ». Ce n’est pas totalement de leur faute, on leur a appris dans leur formation que moins ils ont de candidatures à traiter, moins cela leur prend de temps et plus ils seront efficaces. Sachant cela, n’hésitez pas à postuler à une annonce intéressante, surtout si la liste de compétences vous paraît bullshit. Sur un malentendu, ça peut souvent marcher, et au pire vous n’aurez pas de réponse.

— Avant d’être recruté, demandez à l’entreprise si, sur son projet, elle a un plan de la base (MPD) et une liste commentée des modules (ou une liste commentée d’URL si c’est une appli Web). Si ce n’est pas le cas, c’est bullshit : c’est une des entreprises qui n’a rien à faire de ses développeurs, de son informatique, des gens qui y travaillent et de la maintenance. Quand on a une usine à gaz, on a un plan. Quand on a une application complexe, on a un plan. Quand ce n’est pas le cas, il faut renvoyer le directeur technique. Dans tous les cas, s’il n’y a pas de plan, ce ne sera pas une bonne mission, et je pense que 75 % des entreprises sont dans ce cas-là. Pour moi, c’est un critère sine qua non, quel que soit le nombre de promesses que cette entreprise peut avancer à ses candidats.

­— Si le process de recrutement avance, que vous avez passé les différents entretiens, que l’entreprise a un plan de la base et qu’elle vous a fait une offre : contactez systématiquement quelques anciens employés avant de dire « oui » (merci, LinkedIn !). Ils auront toujours de très bonnes informations à vous donner, que la jolie plaquette commerciale évite soigneusement de mentionner.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *