Le raisonnement qui mène au recrutement
Il est solide, et il repose sur deux arguments difficiles à contester. Un développeur interne connaît votre métier mieux que n'importe quel prestataire ne le connaîtra jamais : il assiste aux réunions, il entend les plaintes des utilisateurs, il comprend pourquoi telle règle de gestion existe. Et il est disponible tout de suite, pour la correction de dix minutes comme pour l'évolution de trois jours.
Sur un logiciel déjà en production, avec un flux régulier de petites demandes, ces deux arguments l'emportent presque toujours. C'est le bon moment pour recruter.
Le coût réel d'un développeur interne
La comparaison est souvent faussée parce qu'on met en regard un salaire brut et un taux journalier d'agence. Ce n'est pas la même chose.
Au salaire chargé s'ajoutent le matériel, les licences, l'outillage, la formation continue indispensable dans ce métier, les congés, et surtout le temps de management. Un développeur seul dans une organisation non technique a besoin d'un interlocuteur capable d'arbitrer ses choix d'architecture. Si personne ne joue ce rôle, les décisions structurantes sont prises sans contrepoids, et vous ne découvrirez leurs conséquences que deux ans plus tard.
Il faut aussi compter le coût du recrutement lui-même, et le risque d'échec de la période d'essai sur un marché où les bons profils ont le choix.
Ce qu'une agence apporte, et ce qu'elle ne remplace pas
Une agence n'est pas un développeur en plus cher. C'est un accès à une équipe complète, mobilisée par phases : un architecte au cadrage, deux développeurs pendant la construction, un profil infrastructure au déploiement, un designer sur les parcours critiques. Aucune de ces personnes n'est nécessaire à temps plein, et c'est précisément l'intérêt.
Elle apporte aussi ce qu'un développeur seul ne peut structurellement pas fournir : une revue de code par un pair, une continuité en cas d'absence, et un engagement contractuel. Chez Koul, le périmètre, le délai et le budget sont fixés avant le premier sprint et font l'objet d'une garantie de livraison. C'est un transfert de risque que le recrutement ne permet pas.
Ce qu'elle ne remplace pas, en revanche : la présence quotidienne, la connaissance implicite du métier, et la capacité à répondre en dix minutes à une question posée dans un couloir. Une agence qui prétend le contraire vend mal.
Le risque le plus courant : le développeur seul
C'est la configuration qui produit le plus de dossiers de reprise. Une entreprise recrute un développeur, souvent bon, souvent motivé. Il construit un outil qui fonctionne. Personne ne relit son code parce que personne n'en a les compétences. Deux ans plus tard, il part.
Ce qui reste est alors un logiciel qui tourne, mais que plus personne ne sait faire évoluer : pas de documentation, pas de tests, des choix techniques que seul l'auteur pouvait expliquer. La reprise coûte souvent plus cher que le développement initial.
Ce n'est pas la faute du développeur. C'est la conséquence mécanique d'une équipe de un, sans relecture et sans filet.
Le modèle qui marche le mieux : les deux
Les organisations les plus efficaces que nous accompagnons ne choisissent pas. Elles confient la construction initiale à une agence, avec un engagement sur le délai et le budget, puis recrutent en interne pendant le projet, en faisant participer la nouvelle recrue aux derniers sprints.
Le transfert de compétences se fait sur du code documenté et testé, pas sur un fichier de reprise rédigé la veille du départ. L'agence reste ensuite en appui sur les sujets ponctuels qui ne justifient pas un poste : sécurité, montée de version majeure, pic de charge.
C'est aussi le seul montage où le développeur recruté arrive sur une base saine, ce qui change radicalement ses chances de rester.
Trancher selon la maturité de votre système
Il n'y a pas de bonne réponse dans l'absolu, il y a une bonne réponse selon l'endroit où vous en êtes.
Vous n'avez pas encore de logiciel : l'agence est presque toujours le bon choix, parce que la phase de construction demande des compétences que vous n'aurez plus besoin d'avoir ensuite.
Vous avez un logiciel en production et un flux continu de demandes : recrutez, et gardez un partenaire externe pour les sujets pointus.
Vous avez un logiciel en production mais plus personne pour le maintenir : c'est un sujet de reprise, pas d'arbitrage entre les deux modèles.
