Comment s’assurer que les développeurs de votre prestataire ne partent pas à la concurrence ?

Soyons clairs dès le départ, il est pratiquement impossible d’empêcher un développeur de partir chez un concurrent.

Cependant, comme tout risque, c’est quelque chose qui se gère, qui se suit et avant d’étudier les actions à mettre en œuvre, il est nécessaire d’évaluer l’impact de ce risque.

Source : Shutterstock

Un impact à relativiser

La clé de votre business ne repose jamais sur un développeur

Ce n’est pas un développeur qui fait la force de votre business. Le produit développé n’est d’ailleurs qu’un élément de la valeur de votre entreprise et ce, que vous soyez éditeur de logiciels, e-commerçant ou acteur de l’IoT. On a souvent le sentiment que le produit développé est l’élément central du business, or ce n’est que très rarement le cas.

Vous avez de l’avance, vous la conserverez

De plus, un développeur seul qui part à la concurrence aura acquis du savoir-faire c’est indéniable, mais ce n’est pas seul qu’il pourra rattraper votre avance sur un sujet. L’impact est donc limité.

Ce n’est pas l’idée qui fait la valeur, mais sa mise en œuvre

Enfin, même s’il arrive à transférer vos idées à votre concurrent, cela ne vous mettra pas à terre. C’est la réalisation et l’organisation de l’entreprise qui fait son succès pas l’idée.

Dites-vous que si vous avez eu une idée, d’autres l’ont sûrement eue avant et que si rien n’est sorti de terre c’est qu’ils n’ont pas réussi à en faire quelque chose de viable d’un point de vue business. Donc là encore, l’impact est limité.

Ceci étant dit, je suis d’accord que ce n’est jamais agréable de voir une personne sur laquelle on a capitalisé partir dans la boîte d’en face. D’autant plus que vous avez le sentiment de ne pas avoir la main, car ce développeur n’est pas salarié chez vous, mais chez un prestataire.

3 points clés pour éviter le départ d’un développeur

Des solutions existent et pour les trouver il suffit de se poser la question de pourquoi un développeur déciderait de partir.

Il y a le plus souvent 3 raisons majeures :

1) Le salaire

C’est un des éléments sur lequel vous avez le moins la main, mais vous pouvez néanmoins choisir de ne mettre le prix comme critère de sélection premier chez votre fournisseur. Plus les tarifs sont bas, plus le salaire est faible et donc soit le risque de départ est grand, soit le développeur n’est pas bon (et dans ce cas peu importe finalement s’il part à la concurrence ;-)).

2) Le bien-être dans l’entreprise

Le développeur n’est pas salarié de votre entreprise, cependant vous pouvez, je dirais même vous devez le considérer comme tel. Un développeur qui se sent impliqué dans le développement du produit, à qui on présente régulièrement les avancées de l’entreprise, la visibilité sur le produit, n’aura pas envie de partir. Alors que si vous ne le considérez que comme un pion interchangeable, il agira comme tel.

Vous devez également, lorsque vous choisissez votre prestataire, lui demander quelle est sa politique/démarche sociale/RH pour limiter le turn-over et fidéliser ses employés. En savoir plus sur la politique RH de Pentalog

3) L’intérêt technique et fonctionnel du projet

On entend souvent des clients demander à leur prestataire de s’occuper de la maintenance de leur produit (« parce que vous comprenez, ces sujets sont moins intéressants et si je donne ça à mon équipe en interne, ça va partir à tour de bras »). Dites-vous qu’avec un prestataire, ce sera pareil. Donc soit ça ne vous dérange pas qu’un développeur parte (la première partie de l’article vous a peut-être convaincu ;-), soit vous voulez l’éviter et dans ce cas il faut donner à votre prestataire les mêmes activités que ce que vous faites en interne. Donc on essaie d’éviter les :

• « tous les leaders sont chez moi et les « petites mains » chez le prestataire »
• « c’est mon équipe qui définit l’architecture et le prestataire se doit d’exécuter »
• « le nouveau framework, ce sera fait chez nous, par contre les TUs c’est côté prestataire », etc.

Et pour la maintenance, une bonne solution est de faire tourner cette activité entre les équipes internes et externes, cela permet de travailler sur des sujets nouveaux, mais également d’être en permanence conscient de la qualité fonctionnelle de l’application, de sa dette technique et faire en sorte que chacun ait une vision fonctionnelle beaucoup plus complète.

Dernier point avant de conclure, il reste le risque, certes faible, que le développeur parte avec une partie des algorithmes. Mais pour vous préserver de cela, vous devez absolument avoir dans le contrat qui vous lie à votre prestataire une clause dans laquelle il s’engage à ce que le code vous appartienne et ne soit pas réutilisé et dans les contrats avec ses salariés, une clause ne leur permettant pas non plus de réutiliser ce qu’ils ont produit dans le cadre de leur contrat de travail.

Le mythe du développeur allant trahir tous les secrets de la boîte à la concurrence est donc similaire à celui du CFO qui partirait avec la caisse. Ce sont des cas qui arrivent, mais qui sont très rares et qui peuvent être évités avec des actions simples.

Et, entre nous, ce n’est pas le développeur qui fait le succès d’une boîte, c’est plutôt l’inverse 😉

Si vous avez une bonne idée mais pas de prestataire pour s’occuper de votre projet, contactez-nous !

Lisez aussi quels sont les signaux précurseurs de la dépression technique et psychologique de votre CTO.

Demande de devis