Constituer Une Équipe De Développement Logiciel

La décision de constituer une équipe de développement logiciel arrive le plus souvent comme une ligne budgétaire, pas comme un plan. Quelqu’un a validé deux postes de développeur, une note au conseil a soutenu que posséder le code coûte moins cher que le louer, et la recherche démarre avant que personne ait écrit à quoi sert l’équipe. Le recrutement dérape alors de façon invisible pendant neuf mois environ.

La plupart de ceux qui posent la question ne devraient pas encore recruter : la réponse honnête part de là. Une équipe permanente est un coût fixe face à un besoin qui varie. Elle fonctionne quand le travail est continu, quand le logiciel est ce que les clients paient, et quand quelqu’un dans l’entreprise sait dire quoi construire la semaine prochaine. Retirez une seule de ces conditions et vous avez acheté à l’année ce que vous pouviez acheter à la journée.

Suivent l’arithmétique et l’ordre des étapes : ce que coûte vraiment un développeur une fois la National Insurance, la retraite, les congés, le matériel et le recrutement dans le chiffre, quel poste ouvrir en premier, ce que livrent des équipes de une, trois, cinq et dix personnes, et comment mener un entretien technique quand personne chez vous n’est technique.

Combien faut-il de personnes pour constituer une équipe de développement logiciel ? Moins que prévu, et plus tard que prévu. Un développeur senior généraliste capable de porter la livraison de bout en bout couvre plus de terrain que trois juniors, car à petite échelle la contrainte est le jugement, pas la frappe. Le premier format vraiment stable est de trois personnes, environ 250 000 GBP par an tout compris. Avec une feuille de route discontinue, une agence est souvent le meilleur instrument.

La plupart des entreprises ne devraient pas encore constituer d’équipe logicielle

Recruter est la façon la plus chère de répondre à une question mal posée. Un contrat de travail vous engage sur un salaire tant que la personne est là, plus le préavis, plus les coûts légaux décrits plus bas, et il le fait avant que vous sachiez si le travail existera encore dans dix-huit mois.

L’échec est rarement spectaculaire. Une entreprise recrute deux développeurs, ils construisent ce qui figure sur la liste, et la liste s’épuise. Personne ne veut licencier, alors l’équipe invente du travail : une réécriture, une montée de version de framework, un outil interne que personne n’a demandé. Douze mois plus tard la masse salariale est réelle, la production ne l’est pas, et le dirigeant conclut que les développeurs sont improductifs. Ils ne l’étaient pas. Ils étaient sous-spécifiés.

Le contre-argument est solide : les agences coûtent plus cher par jour et comprennent moins bien votre métier. Les deux sont vrais. Ce que cela oublie, c’est qu’une agence est un coût variable que vous pouvez couper, donc un mauvais mois coûte un mois et non une année. Quand la feuille de route est réellement continue, le calcul s’inverse et l’interne gagne sur le coût comme sur la vitesse. L’erreur est de l’inverser trop tôt. Un périmètre fixe avec une fin définie relève d’une mission d’agence et non d’un plan de recrutement, ce qui explique que notre service de développement logiciel voie tant d’entreprises arriver avec une question d’effectifs alors qu’elles ont un projet et non un programme.

Le test qui vous dit si vous avez besoin d’une équipe

Trois conditions, et il vous les faut toutes. Moins de trois signifie que vous n’êtes pas prêt.

Le logiciel est-il le produit, ou soutient-il le produit ? Si les clients vous paient pour du logiciel, ou si c’est la raison pour laquelle ils vous choisissent plutôt qu’un concurrent, le code est un actif stratégique et tout externaliser finit par poser un problème de gouvernance. Si le logiciel gère votre facturation, c’est de la plomberie, et la plomberie s’achète.

La feuille de route est-elle continue ? Écrivez ce que vous construiriez des mois quatre à douze. Pas des fonctions qui vous plairaient, du travail que vous pouvez défendre commercialement. Si cette liste est mince, vous avez un projet avec une traîne, pas une année de travail.

Quelqu’un dans l’entreprise sait-il spécifier le travail ? C’est le point que l’on saute. Un développeur doit savoir quel problème résoudre et à quoi vous verrez qu’il est résolu. Si la seule personne capable de répondre est le dirigeant, et qu’il a quarante minutes par semaine, l’équipe passe l’essentiel de son temps à attendre ou à deviner. Une équipe sans product owner produit du mouvement, pas du progrès.

Une quatrième question tranche le calendrier plutôt que la réponse. Pouvez-vous financer dix-huit mois sans que le logiciel génère de revenu ? Si votre trésorerie impose que l’équipe soit rentable au mois six, ne recrutez personne et achetez le travail à la journée.

Ce que coûte réellement un salarié en 2026

Le salaire représente environ soixante-dix pour cent du chiffre. Le reste est légal, opérationnel et ponctuel, et la dernière catégorie ruine les budgets de première année.

Les coûts légaux qui ne se négocient pas

La National Insurance employeur est le plus gros ajout. Pour l’année fiscale 2026 à 2027, les employeurs paient 15 pour cent sur la rémunération dépassant un seuil secondaire de 5 000 GBP par an, selon les taux et seuils GOV.UK pour les employeurs. Sur un salaire de 60 000 GBP, cela fait 15 pour cent de 55 000 GBP, soit 8 250 GBP. Les employeurs éligibles peuvent imputer jusqu’à 10 500 GBP de leur dette annuelle de classe 1 secondaire via l’Employment Allowance, mais une société avec un seul dirigeant et aucun autre salarié redevable de cotisations secondaires ne peut pas la réclamer.

L’adhésion automatique à la retraite ajoute une cotisation employeur minimale de 3 pour cent, à l’intérieur d’un minimum total de 8 pour cent, calculée sur la rémunération éligible comprise entre 6 240 GBP et 50 270 GBP par an d’après les indications GOV.UK sur les cotisations de retraite professionnelle. Cela fait environ 1 321 GBP par salarié en haut de la tranche. Beaucoup d’employeurs versent plutôt un pourcentage du salaire complet, plus généreux et plus simple à expliquer à un candidat.

Les congés sont un coût de capacité, pas de trésorerie. Le droit légal est de 5,6 semaines, soit 28 jours pour cinq jours travaillés par semaine, et les jours fériés n’ont pas à s’y ajouter. Rapporté à quelque 260 jours ouvrés, cela approche onze pour cent de l’année avant toute maladie.

Les coûts absents du tableur

Le matériel est modeste mais réel : un portable à 1 500 ou 2 500 GBP, un écran, un bureau. L’outillage pèse plus qu’on ne croit : gestion de versions, licence d’IDE, minutes d’intégration continue, environnements cloud, suivi d’erreurs, rétention des journaux. De 1 200 à 3 000 GBP par développeur et par an est une base de planification défendable, estimation maison et non statistique publiée.

Le recrutement est le pic. Au Royaume-Uni, un cabinet au succès facture un pourcentage du premier salaire annuel, de la fin de la dizaine au milieu de la vingtaine : prévoyez de 9 000 à 15 000 GBP sur un poste à 60 000 GBP, sauf recrutement direct. Là encore, une estimation maison.

La ligne que personne ne chiffre est l’encadrement. Un senior qui supervise deux collègues perd de vingt à quarante pour cent de sa capacité de livraison : trois recrutements ne produisent donc pas trois personnes de production.

Comptez environ 1,4 fois le salaire la première année et 1,2 fois ensuite, hors encadrement. Les chiffres de salaire, matériel, outillage et recrutement sont des estimations maison ; seules les lignes National Insurance, retraite et congés viennent de taux publiés.

La voie du freelance et ce qu’elle achète vraiment

Un freelance au tarif journalier supprime les coûts légaux et le préavis, et ajoute une prime et une obligation de gouvernance. Au Royaume-Uni, un développeur senior qui facture via sa propre société se situe couramment dans la tranche de 400 à 600 GBP par jour, les compétences rares et les missions courtes se plaçant au-dessus. C’est une estimation maison, cohérente avec les tranches citées ailleurs sur ce site.

À 500 GBP par jour et 220 jours facturables, cela fait 110 000 GBP par an contre 72 000 GBP tout compris pour un salarié à 60 000 GBP. La prime achète trois choses : vous pouvez arrêter, vous pouvez démarrer vite, et vous obtenez quelqu’un qui a déjà résolu ce problème ailleurs. Elle vous coûte la continuité et le savoir qui repart avec le contrat.

Le freelance marche bien pour un manque de compétence circonscrit, pour couvrir une absence, et pour les six premiers mois d’une construction où vous voulez du jugement senior sans engager d’effectifs. Il marche mal en substitut permanent d’une équipe, parce que la structure d’incitations récompense discrètement la durée plutôt que l’achèvement, et parce que personne ne répond du code dix-huit mois plus tard. La version raisonnable est hybride : des freelances pour les pics et les spécialités, des salariés pour les parties du système dont le départ serait intenable. C’est le schéma derrière la plupart de nos missions recruter un développeur web.

Le travail hors paie et ce que les règles exigent de vous

Cette section décrit une obligation. Ce n’est pas un conseil fiscal, et tout contrat de freelance, de toute taille, devrait être vérifié par un expert-comptable ou un spécialiste de la fiscalité de l’emploi avant de démarrer.

Les règles du travail hors paie, dites IR35, s’appliquent lorsqu’une personne fournit des services via son propre intermédiaire et aurait été salariée en contractant directement avec vous. Les indications GOV.UK sur le travail hors paie précisent qui décide. Un client privé moyen ou grand détermine le statut d’emploi du travailleur au regard de l’impôt et doit émettre un Status Determination Statement motivé. Pour un petit client hors secteur public, cette responsabilité revient à l’intermédiaire du travailleur.

Le fait d’être petit suit le test de taille du Companies Act. L’Employment Status Manual de HMRC indique qu’au 6 avril 2025 les seuils sont passés à un chiffre d’affaires supérieur à 15 millions de GBP et un total de bilan supérieur à 7,5 millions de GBP, la limite de 50 salariés restant inchangée. Une société est moyenne ou grande si elle remplit au moins deux des trois critères sur deux exercices consécutifs.

HMRC publie un outil pour la détermination elle-même. L’outil de vérification du statut d’emploi fiscal peut être utilisé par les donneurs d’ordre, les travailleurs ou les agences, et HMRC déclare s’en tenir au résultat si les informations fournies sont exactes et conformes à ses indications. Cette réserve fait tout : un résultat fondé sur le contrat rêvé ne vaut rien.

La conséquence pratique est simple. Les freelances ne sont administrativement moins chers que les salariés que tant que vous êtes petit. Une fois le test de taille franchi, chaque mission porte une détermination, une déclaration et un enregistrement.

Ce que coûte une agence et ce que vous cédez

Au Royaume-Uni, les tarifs journaliers d’agence pour un développeur senior vont couramment de 600 à 1 200 GBP, selon l’ancienneté, le secteur et la part de pilotage de livraison incluse. C’est environ le double d’un freelance et le triple d’une journée de salarié chargée, et la comparaison trompe dans les deux sens.

La prime achète une capacité déjà assemblée. Une escouade d’agence de trois personnes a déjà travaillé ensemble, dispose d’une chaîne de déploiement, d’une astreinte et d’un senior qui relit le code. Monter cela en interne prend six à neuf mois et deux vagues de recrutement. Pour une construction à périmètre fixe, ou une première version où vous apprenez encore ce que le produit doit être, cette avance l’emporte en général sur l’écart de tarif.

Ce que vous cédez, c’est la proximité et la permanence. La compréhension qu’une agence a de votre métier est bornée par ce que vous lui avez dit, et elle part avec elle. La parade, c’est la documentation et une clause de transmission écrite au début, pas à la fin.

Le seuil de rentabilité se raisonne mieux en mois qu’en tarifs. En dessous d’environ neuf mois de travail continu, l’agence revient moins cher une fois chiffrés le recrutement, la montée en charge et le risque d’une mauvaise embauche. Au-delà de dix-huit mois, l’interne gagne nettement. Notre guide pour choisir et engager une agence de développement logiciel traite du choix, et le guide de budget pour un logiciel sur mesure traite des chiffres.

Le premier recrutement technique décide de tout le reste

Tout ce qui suit votre premier recrutement technique découle du jugement de cette personne. Elle choisit le langage, l’hébergement, l’approche de déploiement et le modèle de données, et chaque recrutement suivant est jugé à l’aune d’une pile qu’elle a définie. Une entreprise qui se trompe là ne le découvre pas avant un an, puis le découvre d’un coup.

Recrutez un senior généraliste capable de porter la livraison de bout en bout. Pas un spécialiste de la technologie que vous croyez nécessaire, et pas un manager. Quelqu’un qui sait parler à un client, décider quoi construire, le construire, le mettre en production et le soutenir un mardi soir. Ce profil est cher, environ 70 000 à 95 000 GBP hors Londres selon notre estimation maison, et c’est la chose la moins chère que vous achèterez cette année-là.

Le test en entretien n’est pas de savoir si la personne connaît votre framework. C’est de savoir si elle peut décrire un projet qu’elle a mal cadré et dire ce qu’elle ferait autrement, et si elle demande qui sont vos clients avant de demander quelle est votre pile. Un développeur qui n’interroge que la technologie construira une chose techniquement excellente et commercialement sans intérêt.

Donnez à cette personne de l’autorité, pas seulement un titre. Si elle ne peut pas refuser une demande de fonctionnalité, vous avez recruté une paire de mains très chère. Notre article sur comment recruter un développeur logiciel au Royaume-Uni détaille la sélection.

Pourquoi recruter un junior en premier échoue

La logique est toujours la même et toujours fausse. Un junior coûte 28 000 GBP plutôt que 80 000 GBP, donc vous pouvez en prendre deux, et ils grandiront dans le poste. Ce qui se passe vraiment, c’est que personne n’est là pour les faire grandir.

Un développeur junior est un solde négatif sur la livraison pendant trois à neuf mois. Ce n’est pas une critique, c’est le fonctionnement du métier : il lui faut de la relecture de code, un cadrage d’architecture et quelqu’un pour l’arrêter avant qu’il ne fige une décision coûteuse à défaire. Sans un senior pour le faire, la relecture n’a jamais lieu et le junior expédie du travail non vérifié dans le système qui fait tourner votre entreprise.

La facture arrive plus tard, en dette technique. Réécrire dix-huit mois de code non relu coûte en général plus que le salaire économisé, et le coûte au moment où le logiciel porte déjà l’activité.

Les juniors sont un bon investissement dans le bon ordre. Une fois que vous avez un senior disponible pour encadrer et une base de code avec des tests et un processus de relecture, un junior devient de la capacité bon marché qui se cumule. Recrutés en premier, ils sont un passif non financé doté d’un numéro de paie.

Formats d’équipe : ce que livrent une, trois, cinq et dix personnes

Un organigramme dit qui rend compte à qui. Ce qu’il faut à un acheteur, c’est ce que chaque taille peut réellement mettre en production, et ce qu’elle ne peut structurellement pas.

Un développeur

Un senior généraliste peut construire et exploiter une seule application à surface modeste. Il livre chaque semaine, corrige ses propres incidents de production et garde tout le système en tête, ce qui le rend rapide. Ce qu’il ne peut pas faire, c’est tomber malade, partir en congés ou démissionner. Une équipe d’une personne n’a aucune redondance, et toute entreprise qui tourne sur un développeur porte un risque non chiffré. Couvrez-le par un forfait d’agence pour les absences, ou acceptez-le explicitement plutôt que par défaut.

Trois développeurs

Trois est le premier format qui survit à un départ. Typiquement un responsable technique et deux développeurs, le responsable passant environ la moitié de sa semaine en livraison et l’autre en relecture, planification et déblocage. Trois personnes tiennent deux chantiers, une cadence de mise en production et une astreinte. Elles ne peuvent pas se spécialiser : tout ce qui demande une expertise profonde, une intégration de paiement ou une réécriture de performance, s’achète dehors. Tout compris, cela représente environ 250 000 GBP par an.

Cinq développeurs

À cinq, la structure commence à payer. Vous pouvez désormais vous offrir un spécialiste à côté des généralistes, et le responsable technique cesse d’écrire du code la plupart de la semaine. Cinq personnes tiennent un produit avec une vraie base d’utilisateurs, répondent aux incidents pendant les heures ouvrées et avancent quand même sur la feuille de route. C’est aussi la taille à laquelle l’absence de product owner devient intenable, car le coût de coordination dépasse ce qu’un fondateur absorbe dans les interstices.

Dix développeurs

Dix, ce sont deux équipes, que vous ayez tracé la ligne ou non. Les canaux de communication croissent plus vite que l’effectif, l’informel casse donc et il vous faut une propriété explicite : qui possède quel service, qui est d’astreinte, qui tranche. C’est là que le management technique devient un rôle et non une casquette, et là que le travail de plateforme (déploiement, environnements, observabilité) devient le métier de quelqu’un au lieu de la soirée de tous.

Les rôles expliqués à un lecteur non technique

Les intitulés de poste varient d’une entreprise à l’autre dans le logiciel, ce qui les rend difficiles à acheter. Voici ce que chaque rôle fait de sa semaine.

Product owner

Décide ce qui est construit et dans quel ordre, écrit ce que « terminé » veut dire, et sait dire non. Passe la semaine à parler aux clients et à l’équipe, et à convertir les uns en travail exploitable par l’autre. Sans ce rôle, quelqu’un d’autre le fait mal, souvent le responsable technique, au prix de son temps de livraison. Vous pouvez vous en passer jusqu’à environ cinq développeurs si un fondateur y consacre vraiment un jour par semaine.

Responsable technique

Possède la façon dont le système est construit. Relit le code, tranche l’architecture, et répond du dessin quand il s’avère mauvais. À trois, il code encore presque tous les jours ; à dix, très peu. C’est le rôle que vous ne pouvez sauter à aucune taille au-dessus de un, car c’est de là que vient la cohérence.

Développeur full-stack

Construit des fonctions sur tout le chemin, de l’écran que voit l’utilisateur à la base de données derrière. La colonne vertébrale de toute petite équipe, parce qu’un généraliste ramasse ce qui bloque la mise en production. À petite échelle, recrutez presque exclusivement ce profil.

Spécialiste

Profond sur un domaine : mobile, ingénierie des données, sécurité, un framework précis. Extrêmement utile quand le travail l’exige vraiment, et inoccupé sinon. Achetez les spécialistes à la journée jusqu’à ce que le besoin soit continu pendant au moins six mois.

Ingénieur QA

Teste le système délibérément et non incidemment, construit des suites de tests automatisées, et possède la définition d’une version sûre à publier. Les développeurs testent leur propre travail, mais ils testent ce qu’ils attendaient. Un testeur teste ce qu’un utilisateur fera vraiment.

Ingénieur plateforme

Possède le terrain sur lequel le logiciel tourne : environnements, chaînes de déploiement, supervision, sauvegardes, coûts. Parfois appelé DevOps, qui est proprement une pratique et non un métier. Le travail existe à toute taille ; la question est de savoir s’il est le métier de quelqu’un ou les heures supplémentaires de tous.

Quand un testeur, un designer et un ingénieur plateforme deviennent nécessaires

Chacun a un signal honnête, et c’est un symptôme plutôt qu’un chiffre d’effectif.

Recrutez un testeur dédié quand des régressions atteignent les clients plus d’une fois par trimestre, ou quand les mises en production ralentissent parce que personne n’ose appuyer sur le bouton. Les deux signifient que la vérification manuelle dépasse ce que les développeurs absorbent. Dans une équipe de cinq, cela arrive en général entre le mois douze et le mois vingt-quatre.

Recrutez ou retenez un designer quand les développeurs prennent les décisions d’interface dans la pull request. C’est un défaut d’ordonnancement et non de compétence : on leur demande de concevoir et de construire à la fois, et la moitié conception reçoit le temps qui reste. Un designer à temps partiel suffit bien au-delà de dix développeurs.

Recrutez un ingénieur plateforme quand le déploiement devient un événement plutôt qu’une routine, ou quand la semaine de votre meilleur développeur est dévorée par les environnements et les chaînes. Si publier exige une personne nommée et un après-midi calme, le terrain est devenu le goulot. Notre article sur les bonnes pratiques de chaîne CI/CD décrit ce que bon veut dire avant de recruter pour cela.

Recrutez un manager technique autour de huit à dix personnes, et pas avant. En dessous, un responsable technique doté d’autorité vaut mieux qu’un manager sans crédibilité technique, car les décisions qui comptent à petite échelle sont techniques.

Rédiger une offre d’emploi qui filtre

Une offre d’emploi a une seule tâche : réduire le nombre de candidatures à lire tout en augmentant la proportion de celles qui sont pertinentes. La plupart font l’inverse, parce qu’elles listent des technologies au lieu de problèmes.

Commencez par le problème. « Vous porterez la réécriture d’un système de réservation qui traite 4 millions de GBP par an et perd aujourd’hui environ une commande par semaine » en dit plus à un bon développeur qu’un paragraphe d’adjectifs, et sélectionne ceux que cela intéresse. Nommez la pile en une ligne, présentée comme l’état actuel et non comme une exigence : un bon développeur apprend votre framework en quinze jours et un mauvais n’est pas sauvé par le fait de le connaître déjà.

Publiez la fourchette de salaire. Les postes sans fourchette attirent des gens qui optimisent le volume, et gâchent une boucle d’entretiens entière à découvrir un écart qu’un chiffre aurait montré en dix secondes. Si la fourchette vous met mal à l’aise en public, c’est qu’elle est probablement mauvaise.

Soyez explicite sur la forme de l’équipe, y compris sur le fait qu’elle est petite. « Vous serez notre premier développeur, rattaché au fondateur » attire sincèrement certains et repousse sincèrement d’autres, et vous voulez les deux effets. Le flou ici produit des candidats qui acceptent puis partent au mois quatre.

Coupez ensuite la liste d’exigences à ce qui est réellement exigé. Quatorze puces sont une liste de préférences déguisée en spécification, et elles étouffent les candidatures de gens qui auraient bien fait le travail.

Mener une évaluation technique que vous ne pouvez pas mener

Sans fondateur technique, la tentation est d’évaluer l’assurance, qui ne corrèle avec rien. Structurez le processus pour que le jugement technique se forme là où vous pouvez lui faire confiance.

Utilisez un exercice court, rémunéré, à faire chez soi. Deux à trois heures, payées à un tarif raisonnable, avec un énoncé écrit précisant les contraintes et les critères d’évaluation. Les exercices non payés de plusieurs jours filtrent le temps libre et non la compétence, et vous font perdre exactement les candidats expérimentés que vous visez. Restez près du travail réel : une petite fonctionnalité sur une base de code réaliste prédit mieux le poste qu’une énigme algorithmique.

Faites venir un évaluateur technique externe pour la relecture et l’entretien de suivi. Une heure d’un développeur senior qui lit le rendu et fait dérouler ses décisions au candidat vous apprend plus que n’importe quel volume de questions de compétences. Prévoyez un tarif journalier et voyez-le comme une assurance peu chère contre un recrutement qui coûte une année.

Demandez au candidat de vous expliquer son code, à vous qui n’êtes pas technique. S’il ne peut pas décrire ce qu’il a construit et pourquoi dans des termes que vous suivez, c’est une information : l’essentiel du poste consiste à parler à des gens qui ne sont pas développeurs.

Prenez les références sérieusement, et posez une question précise : qu’a fait cette personne quand elle n’était pas d’accord avec une décision. La réponse sépare les développeurs qui soulèvent les problèmes tôt de ceux qui se taisent et construisent correctement la mauvaise chose.

Les vérifications du droit de travailler ne sont pas facultatives

Tout employeur doit vérifier qu’un candidat a le droit de travailler au Royaume-Uni, et la vérification doit être terminée avant le début de l’emploi. Les indications GOV.UK sur la vérification du droit de travailler d’un candidat exposent trois méthodes acceptables : un contrôle en ligne par code de partage, un contrôle manuel des documents originaux en présence du candidat, ou un contrôle par un prestataire d’identité certifié utilisant une technologie de validation des documents d’identité. Les ressortissants britanniques et irlandais ne peuvent pas obtenir de code de partage : leur contrôle passe donc par les documents ou par un prestataire d’identité.

Conservez les copies pendant la durée de l’emploi et deux ans après, et programmez un nouveau contrôle pour toute personne dont l’autorisation de travail est limitée dans le temps. C’est ce dossier qui établit l’excuse légale si un problème est constaté plus tard.

L’exposition n’est pas mince. GOV.UK indique qu’un employeur peut encourir une amende civile pouvant atteindre 60 000 GBP par travailleur illégal lorsque le contrôle correct n’a pas été effectué. Pour une entreprise qui fait ses deux premiers recrutements, c’est plus que tout le budget de recrutement. Intégrez le contrôle au processus d’offre plutôt qu’au premier jour, afin qu’aucune date d’arrivée n’arrive avec des papiers en suspens.

Recruter hors du Royaume-Uni

Si le candidat que vous voulez n’a pas déjà l’autorisation de travailler ici, il vous faut une licence de sponsor avant de pouvoir l’employer, et c’est un projet plutôt qu’un formulaire.

Demander une licence Worker coûte 611 GBP pour un sponsor petit ou caritatif et 1 682 GBP pour un moyen ou grand, selon les indications GOV.UK sur le parrainage. La plupart des décisions tombent en moins de huit semaines, avec un service prioritaire à 750 GBP offrant une décision en dix jours ouvrés quand des créneaux existent. Tablez sur le délai standard, car cette file se traite par ordre d’arrivée.

Le poste lui-même doit franchir un plancher de salaire. Le visa Skilled Worker exige un sponsor licencié et un certificat de parrainage, et GOV.UK fixe l’exigence salariale standard à 41 700 GBP par an ou au taux en vigueur pour la profession, le plus élevé des deux s’appliquant. Pour la plupart des postes logiciels, c’est le taux en vigueur, et non le seuil général, qui contraint.

Vient ensuite l’Immigration Skills Charge, payable par l’employeur à l’attribution du certificat de parrainage. GOV.UK la fixe à 480 GBP pour les douze premiers mois pour un sponsor petit ou caritatif et à 1 320 GBP pour un moyen ou grand, avec 240 GBP ou 660 GBP par semestre supplémentaire. Sur un parrainage de trois ans pour un employeur moyen, cela fait 3 960 GBP, et le sponsor ne peut pas la répercuter sur le travailleur.

Prévoyez de 6 000 à 9 000 GBP et trois à quatre mois pour un premier recrutement parrainé. C’est souvent juste pour une compétence rare, et presque jamais pour un premier poste dont vous avez besoin en six semaines.

L’intégration et les quatre-vingt-dix premiers jours

Fixez une cible mesurable : le nouveau développeur met quelque chose en production dès la première semaine. Pas une fonctionnalité majeure, un petit changement réel que les clients voient. C’est le test le plus rapide de la viabilité réelle de votre environnement, et cela fait passer la personne recrutée du statut d’observateur à celui de propriétaire.

Plusieurs choses doivent être vraies pour cela. Une installation locale documentée qui fonctionne sur une machine neuve. Des comptes et des accès préparés avant le premier jour plutôt que demandés le jour même. Un chemin de déploiement qui ne réclame pas la bénédiction d’une personne précise. Un parrain nommé dont l’agenda est vraiment libre cette semaine-là. S’il en manque un, la première chose que votre nouveau développeur apprend, c’est que vos systèmes ne marchent pas.

Au jour trente, il devrait avoir livré une fonctionnalité significative et savoir décrire l’activité, pas seulement la base de code. Au jour soixante, il devrait relire le code des autres et contester des décisions. Au jour quatre-vingt-dix, il devrait identifier le travail plutôt que le recevoir.

Ces jalons sont aussi votre système d’alerte précoce. Une recrue qui ne conteste rien au jour soixante est soit mal appariée, soit trop encadrée, et les deux se corrigent au mois trois pour une fraction de ce qu’ils coûtent au mois neuf. Notre article sur l’intégration des développeurs qui livre dès la première semaine en expose la mécanique.

La fidélisation, chiffrée plutôt que racontée

Remplacer un développeur coûte les honoraires de recrutement, la montée en charge, et la production que le partant a cessé de fournir dès sa démission. Sur un poste à 60 000 GBP, 12 000 GBP d’honoraires plus trois mois de production réduite portent le chiffre réel au-delà de 25 000 GBP. C’est une estimation maison, et prudente, car elle exclut le savoir qui s’en va avec lui.

Les développeurs partent rarement pour l’argent seul, même si l’argent est la raison qu’ils donnent. Ils partent parce qu’ils ne peuvent pas livrer. Un déploiement qui prend trois jours, une file de relecture que personne ne vide, une feuille de route qui change tous les quinze jours, six mois de travail annulés avant la sortie. Chacun dit à une personne compétente que son effort ne se convertit pas en résultats, et les gens compétents ont des options.

La dépense de fidélisation commercialement rationnelle n’est donc pas dans les avantages. Elle est dans l’automatisation du déploiement, un processus de relecture qui fonctionne, une feuille de route stable et assez de marge pour que la maintenance ait lieu avant de devenir une urgence. Ce sont les mêmes investissements qui augmentent la vitesse de livraison.

Les grilles de salaire comptent encore, d’une façon précise. Les salaires dérivent quand le marché bouge et que les revues internes ne bougent pas, et la première personne qui s’en aperçoit est celle qui passe des entretiens ailleurs. Révisez les grilles chaque année contre des données publiques comme le bulletin ONS sur les revenus des salariés au Royaume-Uni, qui situe le revenu annuel brut médian des salariés à temps plein à 39 039 GBP en avril 2025. Cela coûte bien moins qu’une démission.

Le modèle hybride où atterrissent la plupart des entreprises

Après dix-huit mois, la plupart des entreprises parties pour monter une équipe interne finissent au milieu : un petit noyau permanent qui possède le produit, avec une agence ou des freelances rattachés pour les spécialités et les pics. Ce n’est pas un échec du plan. C’est l’arrangement qui survit au contact d’une vraie feuille de route.

Il fonctionne quand trois choses sont vraies. L’équipe interne possède l’architecture et l’environnement de production, si bien que le partenaire externe contribue dans une structure que vous contrôlez au lieu d’en définir une. La relecture de code va dans les deux sens : le travail externe est relu par votre équipe et celui de votre équipe par la leur. Et le périmètre du partenaire externe est écrit en résultats, pas en heures.

Il échoue quand l’agence devient une boîte noire. Le signe, c’est que personne en interne ne sait expliquer comment un composant marche. Empêchez-le structurellement : le travail externe atterrit dans votre dépôt, se déploie par votre chaîne, et est documenté comme condition de paiement plutôt que par courtoisie à la fin. Gardez au contrat une séance de transfert de connaissances à cadence fixe, mensuelle suffit en général. Notre comparaison sur l’externalisation du développement logiciel, Royaume-Uni contre offshore mérite d’être lue avant de choisir où siège la moitié externe, car le recouvrement de fuseaux change nettement la qualité du modèle.

Un plan par étapes pour les dix-huit premiers mois

Mois un à trois : ne recrutez pas. Écrivez la feuille de route des mois quatre à dix-huit et faites-la relire par quelqu’un de technique qui ne vous vend rien. Achetez le travail immédiat à une agence ou à un freelance. Le produit de cette étape est une réponse défendable à la question de la continuité du travail.

Mois quatre à neuf : recrutez le senior généraliste. Une personne, bien payée, avec autorité sur les décisions techniques. Gardez la capacité externe en parallèle les deux premiers mois pour que la livraison ne s’arrête pas pendant qu’elle prend ses marques. Point de décision au mois neuf : la feuille de route est-elle encore pleine, et cette personne sait-elle spécifier du travail pour d’autres.

Mois dix à quinze : si les deux réponses sont oui, ajoutez deux développeurs pour atteindre le format stable de trois, et nommez un product owner même s’il s’agit d’un fondateur qui alloue formellement un jour par semaine. Si une réponse est non, restez à une personne plus de la capacité externe, ce qui est un état permanent parfaitement valable pour une entreprise dont le logiciel soutient le produit au lieu de l’être.

Mois seize à dix-huit : le second point de décision. N’ajoutez les quatrième et cinquième personnes que si la contrainte est vraiment la capacité et non la direction. Les équipes grandissent plus souvent pour la mauvaise raison que pour la bonne, et le symptôme est un backlog long mais non priorisé. À chaque point de décision, demandez si le prochain recrutement va plus vite que la prochaine journée d’agence.

Par où commencer

Écrivez d’abord la feuille de route à dix-huit mois, répondez honnêtement au test en trois volets, puis chiffrez les deux voies avec les vrais nombres et pas seulement le salaire. La plupart des entreprises découvrent que le premier recrutement devrait être une personne senior plutôt que deux profils intermédiaires, et que les six mois qui précèdent s’achètent mieux à la journée.

Mecanik travaille des deux côtés. Nous menons des missions de développement logiciel pour des entreprises qui ne sont pas prêtes à recruter, et nous fournissons de la capacité senior via recruter un développeur web aux équipes qui bâtissent un noyau et veulent couvrir les pics pendant ce temps. Si vous pesez les deux, la conversation utile porte sur la feuille de route, car c’est elle qui tranche.

Questions fréquentes

Combien coûte le recrutement d’un développeur logiciel au Royaume-Uni ? Comptez environ 1,4 fois le salaire la première année et 1,2 fois ensuite. Sur un salaire de 60 000 GBP, cela fait à peu près 85 600 GBP la première année, composés du salaire, de la National Insurance employeur à 15 pour cent au-delà du seuil secondaire de 5 000 GBP pour l’année fiscale 2026 à 2027, d’une cotisation retraite minimale de 3 pour cent sur la rémunération éligible, du matériel, de l’outillage et d’honoraires de recrutement. Les chiffres de salaire, de matériel, d’outillage et de recrutement sont des estimations maison de planification.

Mon premier recrutement technique doit-il être un senior ou un junior ? Un senior, et un généraliste plutôt qu’un spécialiste. Un développeur junior est un solde négatif sur la livraison pendant trois à neuf mois et a besoin d’un senior pour relire son travail : le recruter en premier crée donc du code non vérifié dans un système dont votre entreprise dépend. La réécriture coûte en général plus que le salaire économisé. Les juniors sont un bon investissement une fois qu’un senior disponible pour encadrer et un processus de relecture existent déjà.

Combien de développeurs faut-il pour constituer une équipe de développement logiciel ? Trois est le plus petit format qui survit à un départ : un responsable technique plus deux développeurs, soit environ 250 000 GBP par an tout compris. Un senior généraliste peut faire tourner une seule application mais n’offre aucune redondance en cas de maladie, de congés ou de démission. À cinq, un spécialiste et un product owner dédié commencent à se rentabiliser, et dix, ce sont de fait deux équipes qui exigent une propriété explicite des services.

Quand une agence vaut-elle mieux que des développeurs internes ? Quand le travail a une fin définie, quand vous avez moins de neuf mois environ de feuille de route continue, ou quand il vous faut de la capacité avant qu’une vague de recrutement puisse la fournir. Une agence est un coût variable que vous pouvez arrêter, donc un mauvais mois coûte un mois et non une année. Au-delà de dix-huit mois de travail continu, une équipe interne gagne nettement sur le coût comme sur la vitesse.

Que dois-je vérifier avant d’employer un développeur au Royaume-Uni ? Terminez une vérification du droit de travailler avant le début de l’emploi, au moyen d’un code de partage en ligne, des documents originaux en présence du candidat, ou d’un prestataire d’identité certifié. GOV.UK indique que l’amende civile peut atteindre 60 000 GBP par travailleur illégal lorsque le contrôle correct n’a pas été effectué. Si vous parrainez une personne venue de l’étranger, il vous faut aussi une licence de sponsor, un certificat de parrainage et l’Immigration Skills Charge.