Faut-il recruter sa propre équipe de développement ou confier son application à une agence ? Internaliser se justifie quand l’application est stratégique, évolue en continu et occupe durablement une équipe complète. Externaliser auprès d’une agence est plus adapté quand le besoin est ponctuel, quand il faut démarrer vite ou quand les compétences sont trop rares pour être recrutées une à une. Entre les deux, les modèles mixtes (agence pilotée par un responsable produit interne, puis internalisation progressive) sont souvent la réponse la plus solide pour une PME ou une ETI.
Ce guide vous aide à trancher avec des critères concrets, à chiffrer en temps et en risques ce que l’on oublie souvent, et à préparer dès le départ une éventuelle reprise en interne.
Internaliser, externaliser : de quoi parle-t-on exactement ?
Le débat est souvent mal posé, car il oppose deux options alors qu’il en existe au moins cinq :
- L’équipe interne : des salariés qui conçoivent, développent et maintiennent l’application, encadrés par un responsable technique de l’entreprise.
- L’agence en mode projet : une équipe pluridisciplinaire externe qui prend en charge la conception, le développement et souvent la maintenance, avec un engagement sur le résultat.
- La régie (assistance technique) : un prestataire, souvent une ESN, met des profils à disposition et facture au temps passé ; le pilotage reste chez le client.
- Le freelance : un indépendant, efficace sur un périmètre restreint, avec un risque de dépendance à une seule personne.
- Le modèle mixte : une combinaison des précédents, par exemple une agence qui construit et une équipe interne qui reprend progressivement.
Notre article sur le choix entre forfait et régie détaille les implications contractuelles de chaque formule. Ici, la question est stratégique : qui détient la compétence, et pour combien de temps ?
Quels critères font pencher la balance ?
Six critères suffisent à éclairer la plupart des situations.
| Critère | Plutôt équipe interne | Plutôt agence |
|---|---|---|
| Place de l’application | Cœur de l’offre ou de l’avantage concurrentiel | Outil de support, important mais non différenciant |
| Volume de travail | Évolutions continues, sur plusieurs années | Projet avec un début et une fin, puis maintenance |
| Délai de démarrage | Quelques mois de recrutement sont acceptables | Il faut produire dans les semaines qui viennent |
| Compétences nécessaires | Stables et bien identifiées | Variées ou rares (conception d’interface, sécurité, données, IA) |
| Capacité d’encadrement | Un responsable technique expérimenté existe ou peut être recruté | Personne en interne ne peut évaluer le travail technique |
| Charge dans le temps | Régulière | Irrégulière, avec des pics |
Un projet qui coche surtout la colonne de droite aujourd’hui peut basculer à gauche dans trois ans. Une entreprise qui transforme un outil interne en SaaS, par exemple, passe souvent d’un besoin ponctuel à un besoin permanent. C’est pourquoi la décision doit se reposer à chaque grande étape, pas une fois pour toutes.
Ce que coûte vraiment une équipe interne
Le salaire n’est qu’une partie du sujet. Une équipe interne a un coût d’installation et des risques qu’on sous-estime presque toujours.
Le recrutement prend du temps
Les métiers du développement restent parmi les plus difficiles à recruter en France. Selon l’Insee, l’indicateur de tension du métier d’ingénieur de l’informatique atteignait 1,1 en 2023, ce qui le place parmi les 10 % des métiers les plus tendus sur la période 2011-2022, même si la tension a reculé depuis son pic de 2018. Concrètement, il faut prévoir plusieurs mois entre l’ouverture d’un poste et la première contribution utile, puis une période d’intégration pour apprendre le métier de l’entreprise.
Une équipe viable couvre six rôles
Une application métier en production demande au minimum :
- Un responsable produit qui priorise, arbitre et parle aux utilisateurs.
- De la conception d’interface, pour que l’outil soit adopté.
- Du développement, idéalement par au moins deux personnes qui relisent le code l’une de l’autre.
- Des tests, automatisés et manuels.
- De l’exploitation : hébergement, sauvegardes, supervision, mises à jour de sécurité.
- Un encadrement technique : choix d’architecture, dette technique, recrutement.
Une même personne peut tenir plusieurs rôles, mais pas tous. Le scénario le plus fréquent dans une PME, un développeur unique qui fait tout, est aussi le plus fragile.
Le risque de la personne unique
On parle parfois de « facteur bus » : combien de personnes peuvent partir avant que plus personne ne sache faire évoluer le système ? Avec un seul développeur, la réponse est une. Un départ, un arrêt maladie ou une démission transforme alors un outil critique en boîte noire. C’est la situation que décrit notre article sur la dette technique expliquée aux dirigeants : la connaissance non écrite est une dette comme une autre.
Le management technique ne s’improvise pas
Recruter, évaluer, faire progresser et retenir des développeurs exige un encadrant qui maîtrise le sujet. Sans lui, la direction ne sait pas juger si le travail avance bien, si l’architecture tient la route ou si la sécurité est traitée. Les indicateurs DORA aident à mesurer la performance de livraison, mais encore faut-il quelqu’un pour les interpréter et agir.
Ce qu’une agence apporte, et ce qu’elle ne remplace pas
Une agence spécialisée en applications web sur mesure apporte d’abord une équipe déjà constituée : conception, développement, tests et exploitation travaillent ensemble dès la première semaine, avec une méthode rodée. Elle apporte aussi une expérience transversale : elle a déjà rencontré vos problèmes chez d’autres clients, et sait quelles solutions tiennent dans la durée. Enfin, elle offre de l’élasticité : on peut renforcer l’équipe pendant une phase intense, puis la réduire en maintenance.
En revanche, une agence ne remplace jamais trois choses :
- Le responsable produit côté client. Quelqu’un dans l’entreprise doit fixer les priorités, trancher entre les demandes des services et valider ce qui est livré. Sans ce rôle, le meilleur prestataire construit au mieux ce qu’il a compris.
- La connaissance fine du métier. L’agence l’acquiert par des ateliers et des démonstrations régulières, mais elle reste détenue par vos équipes.
- La responsabilité des décisions. Choisir de lancer, de reporter ou d’abandonner une fonctionnalité est une décision de l’entreprise.
La loi de Conway, formulée par Melvin Conway en 1968 et rappelée par Martin Fowler, éclaire ce point : un système reproduit la structure de communication de l’organisation qui le conçoit. Si l’agence et l’entreprise ne se parlent qu’à travers un cahier des charges et des réunions mensuelles, l’application en portera la trace. C’est pourquoi nous livrons une version utilisable à chaque sprint et la montrons aux utilisateurs, comme décrit dans notre méthode.
Pour bien choisir le prestataire lui-même, notre guide des questions à poser à une agence de développement complète cette réflexion.
Les modèles mixtes : souvent la meilleure réponse
Entre le tout interne et le tout externe, quatre combinaisons fonctionnent bien dans les PME et les ETI.
| Modèle | Fonctionnement | Adapté quand |
|---|---|---|
| Agence + responsable produit interne | L’agence conçoit et développe ; un salarié pilote les priorités et la recette | Première application métier, pas d’équipe technique |
| Construction externe, reprise progressive | L’agence construit, l’entreprise recrute en cours de projet, les nouvelles recrues travaillent en binôme avec l’agence avant de reprendre la main | L’application deviendra stratégique et évoluera en continu |
| Équipe interne renforcée | Une petite équipe interne garde le cœur ; une agence intervient sur des compétences ponctuelles (conception d’interface, intégrations, sécurité) | Une équipe existe mais ne couvre pas tous les rôles |
| Cœur interne, projets satellites externes | L’équipe interne maintient le système central ; l’agence livre des projets autour (portail client, application terrain, intégrations) | La charge dépasse durablement la capacité interne |
Le deuxième modèle s’inspire de ce que l’on appelle parfois « construire, exploiter, transférer » : le prestataire monte et fait fonctionner l’activité, puis la transfère au client selon un calendrier convenu. Pour une application métier, le transfert porte moins sur une équipe que sur une compétence : code, documentation, habitudes de travail et connaissance des choix passés.
Régie et assistance technique : attention au cadre juridique
Quand une entreprise renforce son équipe avec des développeurs externes intégrés au quotidien, elle doit veiller au cadre juridique. L’article L8241-1 du Code du travail interdit toute opération à but lucratif ayant pour objet exclusif le prêt de main-d’œuvre, hors cadres autorisés comme le travail temporaire.
Une prestation de service licite repose sur une tâche définie, une expertise propre au prestataire et l’autonomie de son personnel. En pratique, c’est le prestataire qui organise et encadre le travail de ses équipes ; le client exprime des besoins et valide des livrables, il ne donne pas d’ordres individuels comme à ses salariés. Ce sujet relève de votre conseil juridique, mais il mérite d’être posé avant de signer un contrat de régie de longue durée.
Préparer l’internalisation dès le premier jour
Même si vous ne comptez pas internaliser, comportez-vous comme si vous alliez le faire. Ces exigences rendent aussi un prestataire plus facile à remplacer, ce qui est sain pour tout le monde.
- Le code et les accès vous appartiennent : dépôt de code, hébergement, noms de domaine, comptes des services tiers, au nom de l’entreprise. Voir propriété du code source et réversibilité.
- La documentation est tenue à jour au fil des sprints, pas rédigée en urgence à la fin : installation, architecture, exploitation. Notre article sur la documentation qui sert vraiment détaille ce qu’il faut exiger.
- Les décisions d’architecture sont écrites, avec leur contexte : pourquoi ce choix, quelles alternatives ont été écartées.
- Les tests automatisés et le déploiement sont outillés, pour qu’une nouvelle équipe puisse modifier le code sans crainte.
- Une période de binôme est prévue au contrat avant toute reprise : les nouvelles recrues développent avec l’équipe sortante pendant plusieurs sprints.
- La maintenance est formalisée, avec ses niveaux de service : c’est le sujet de notre article sur la maintenance et la TMA.
La grille de décision en sept questions
Répondez honnêtement à ces questions avec votre comité de direction :
- L’application fait-elle partie de ce que vos clients achètent, ou sert-elle à mieux produire ce qu’ils achètent ?
- Aurez-vous assez de travail pour une équipe complète pendant au moins trois ans ?
- Pouvez-vous recruter et retenir un responsable technique capable d’encadrer cette équipe ?
- Combien de temps pouvez-vous attendre avant la première version utilisable ?
- Qui, dans l’entreprise, tiendra le rôle de responsable produit, avec du temps réellement dégagé ?
- Que se passe-t-il si la personne clé du projet part demain ?
- Avez-vous prévu, par contrat, de pouvoir reprendre l’application ou changer de prestataire ?
Si vous répondez « oui » aux questions 1 à 3, l’internalisation mérite d’être planifiée, souvent après une phase de construction accompagnée. Si les réponses sont surtout négatives, une agence avec un responsable produit interne est le choix le plus sûr. Dans tous les cas, la question 7 doit recevoir un « oui ».
Vous hésitez entre plusieurs modèles pour votre projet ? Décrivez votre contexte dans notre diagnostic de projet : en deux minutes, vous obtenez une première lecture de votre situation, et nous pouvons ensuite en discuter avec vous.
