Intégrer un développeur externe dans son équipe : accès, méthode, revue de code

Intégrer un développeur externe, c’est lui donner en quelques jours ce qu’un salarié reçoit en quelques mois : les accès, le contexte, les règles de l’équipe. Mal préparée, son arrivée fait perdre des semaines et ouvre des accès qu’on oublie de refermer. Bien préparée, elle tient en une liste : un contrat signé avant le premier accès, des comptes à son nom et limités, un environnement qui s’installe sans aide, une première tâche livrée vite, une revue de code systématique, et un départ prévu dès l’arrivée.

Ce guide s’adresse aux dirigeants, aux CTO et aux responsables techniques qui accueillent un freelance, un développeur d’une société de services ou une équipe en régie à distance. Il ne donne ni durée type ni tarif : il donne l’ordre des choses et les points à ne pas oublier.

Que préparer avant l’arrivée d’un développeur externe ?

Avant l’arrivée d’un développeur externe, trois choses doivent être prêtes : le cadre écrit, un référent dans l’équipe et un premier lot de travail. Ce qui n’est pas réglé avant le premier jour se règle rarement après, parce que le travail a commencé.

• Le contrat de prestation signé, avec la cession des droits sur le code, une clause de confidentialité et la réversibilité : ce que deviennent le code, la documentation et les accès à la fin.
• Si le développeur peut voir des données personnelles, les clauses de sous-traitance de l’article 28 du RGPD : la CNIL déconseille de commencer une prestation sans un contrat qui les reprend.
• Un référent nommé chez vous, disponible pour répondre aux questions et relire le code pendant les premières semaines.
• Une documentation minimale à jour : comment installer le projet, comment il est déployé, où sont notées les décisions d’architecture.
• Trois ou quatre tickets prêts, décrits et classés par priorité, dont un petit pour commencer.

Le contrat ne se résume pas au prix. Notre guide du contrat de maintenance applicative détaille les clauses de propriété, de sécurité et de réversibilité ; elles valent aussi pour un renfort en régie.

Quels accès donner à un développeur externe ?

Un développeur externe reçoit des comptes à son nom, avec les seuls droits dont il a besoin pour ses tâches. C’est le principe du moindre privilège, que la CNIL recommande pour toute habilitation : définir des profils d’accès, faire valider chaque demande par un responsable, supprimer les accès dès qu’ils ne sont plus nécessaires et revoir les habilitations au moins une fois par an.

Les données méritent une attention particulière : développer sur une copie de la production expose des données personnelles à des personnes qui n’en ont pas besoin. Notre guide sur les données de test et le RGPD explique comment tester sans copier la production.

Comment le rendre productif dès la première semaine ?

Un développeur externe devient productif quand il a livré une première modification réelle, de son poste jusqu’à la production. L’objectif de la première semaine n’est pas de tout comprendre : c’est de faire passer un petit changement par tout le circuit, et de voir où il bloque.

• Premier jour : les comptes ouverts, l’environnement local installé à partir de la documentation, un échange avec le référent sur l’architecture et les priorités.
• Les jours suivants : une première tâche petite et réelle (une correction, un libellé, un test manquant), relue puis fusionnée.
• En fin de semaine : cette tâche déployée par le circuit habituel, et la liste de ce qui a manqué dans la documentation.
• Ensuite : des tâches de taille croissante, sur des parties différentes de l’application.

Ce que le nouveau venu a eu du mal à installer ou à comprendre est une information précieuse : demandez-lui de compléter lui-même la documentation au fil de l’eau. Elle servira au suivant, et elle révèle souvent une part de la dette technique que l’équipe ne voit plus.

Associez-le aux rituels de l’équipe dès le premier jour : point quotidien, planification, démonstrations. Un développeur externe tenu à l’écart des discussions produit du code conforme au ticket, pas forcément au besoin.

Comment organiser la revue de code ?

Toute modification d’un développeur externe passe par une demande de fusion (pull request) relue par un membre de l’équipe, sur une branche que personne ne peut modifier directement. Ce n’est pas de la méfiance : c’est la règle qui garde un code cohérent quand plusieurs personnes y travaillent, internes comme externes.

Les plateformes de code le permettent sans outil supplémentaire. Sur GitHub, une règle de protection de branche peut exiger un nombre d’approbations avant toute fusion, l’accord des propriétaires désignés d’une partie du code (fichier CODEOWNERS) et la réussite des vérifications automatiques. GitLab et Bitbucket proposent des réglages équivalents.

• Une branche principale protégée : aucune modification sans demande de fusion approuvée.
• Des vérifications automatiques avant la relecture humaine : tests, analyse statique, formatage. La relecture porte alors sur la logique, pas sur la mise en forme.
• Des critères de revue écrits : conventions de nommage, tests attendus, sécurité, documentation.
• Un délai de relecture convenu, pour qu’une demande ne reste pas bloquée des jours.
• Des demandes de fusion courtes : une modification par demande, plus facile à relire et à annuler.

La revue va dans les deux sens. Un développeur senior venu de l’extérieur voit ce que l’équipe ne remarque plus : l’inviter à relire aussi le code des autres accélère sa compréhension du projet et fait remonter des points utiles. Pour que les vérifications automatiques aient du sens, les tests automatisés sont souvent le premier chantier.

Qui pilote le travail, qui encadre le développeur ?

Dans une prestation, le client exprime le besoin, fixe les priorités et valide le travail livré ; le prestataire encadre son développeur : affectation, congés, évaluation, remplacement en cas d’absence. Cette répartition n’est pas qu’une affaire d’organisation : en France, elle touche au cadre légal de la prestation.

Le Code du travail interdit « toute opération à but lucratif ayant pour objet exclusif le prêt de main-d’oeuvre », en dehors des cas qu’il prévoit comme le travail temporaire (article L8241-1). Il interdit aussi le marchandage, une fourniture de main-d’œuvre à but lucratif qui cause un préjudice au salarié ou élude la loi ou une convention collective (article L8231-1). Ces textes ne tracent pas eux-mêmes la frontière entre une prestation de services et un prêt de main-d’œuvre : elle dépend de la façon dont la prestation se déroule réellement. Pour un montage précis, un avocat en droit du travail vous répondra mieux qu’un guide.

En pratique, quelques repères gardent la répartition claire :

• Vous fixez les priorités et validez le travail par les tickets et les rituels de l’équipe ; le prestataire organise la façon de les tenir.
• Les congés, les horaires et l’évaluation du développeur relèvent de son employeur.
• Un interlocuteur côté prestataire, un lead ou un responsable de compte, suit la prestation et organise le remplacement en cas d’absence.
• Les livrables, le volume et les délais se discutent avec ce responsable, au rythme convenu.

Le modèle de facturation compte aussi : au forfait, le prestataire s’engage sur un résultat ; en régie, sur des compétences et du temps. Notre guide TMA au forfait ou en régie compare ce que chaque modèle engage.

À qui appartient le code écrit par un développeur externe ?

Le code écrit par un développeur externe n’appartient pas automatiquement à l’entreprise qui le paie. Bpifrance Création le rappelle : le donneur d’ordre ne devient pas titulaire des droits de plein droit, un contrat de cession doit être conclu, et sans ce contrat « le prestataire reste propriétaire du code livré ». Pour un salarié, à l’inverse, les droits sur un logiciel créé dans le cadre de son travail reviennent à l’employeur sans clause particulière.

Vérifiez donc que la cession des droits figure au contrat de prestation, ou en annexe, avant la première ligne de code. Vérifiez aussi que le dépôt de code, l’hébergement et les comptes de services tiers sont au nom de votre entreprise, pas à celui du développeur ni de son employeur. Notre guide de la reprise d’application web montre ce que coûte un oubli sur ce point, le jour où il faut changer de prestataire.

Comment préparer son départ dès le premier jour ?

Le départ d’un développeur externe se prépare à son arrivée : c’est à ce moment qu’on sait quels accès il reçoit et ce qu’il faudra documenter. Préparé, un départ se règle en une passation ; improvisé, il laisse des comptes ouverts et des connaissances dans une seule tête.

• Une liste des accès ouverts, tenue dès le premier jour, qui devient la liste des accès à fermer le dernier.
• La suppression des comptes le jour du départ, et le changement des secrets qu’il a pu voir.
• Une documentation tenue au fil de l’eau, plutôt qu’écrite la dernière semaine.
• Un temps de passation avec la personne qui reprend ses sujets.
• La restitution du code, de la documentation et des données prévue au contrat.

La CNIL classe parmi les erreurs à éviter le fait d’oublier de supprimer les comptes des personnes qui ont quitté l’organisation. Côté prestataire, la continuité se demande aussi : remplacement en cas d’absence et transfert de connaissances font partie de ce qu’un renfort sérieux prévoit.

Questions fréquentes

Une intégration se prépare comme une mise en production

Intégrer un développeur externe, c’est une suite de gestes simples dans le bon ordre : signer, ouvrir le strict nécessaire, faire livrer vite, tout relire, et préparer le départ dès l’arrivée. Ces règles protègent votre code et vos données ; elles rendent aussi le développeur utile plus tôt.

Les développeurs dédiés d’iones rejoignent vos outils, vos rituels et vos conventions, depuis notre équipe nearshore en Tunisie, encadrés par un lead iones qui organise la continuité et le transfert de connaissances. Pour en parler, écrivez-nous.