Devrais-je engager un développeur ou une agence pour bâtir mon application?
Un seul développeur solide est plus rapide et moins cher quand la portée est claire et modeste. Une agence justifie sa prime par l’étendue de ses services — design, développement côté serveur, assurance qualité, gestion de projet — et par la continuité quand quelqu’un part. Le risque avec un seul développeur, c’est de tout faire reposer sur une seule personne; le risque avec une agence, c’est de payer pour une coordination dont vous n’avez pas besoin.
Chiffrez honnêtement les deux risques, parce qu’ils sont de nature différente. Le risque du développeur seul, c’est la concentration : une seule personne détient le savoir, les accès et l’horaire, et si elle devient trop occupée, tombe malade ou se lasse, votre projet hérite de sa situation — six mois plus tard, quand une API change, il n’y a peut-être plus personne à appeler. Le risque de l’agence, c’est la dilution : votre problème est relayé par un chargé de compte à une équipe que vous ne rencontrez jamais, chaque heure de ce relais est facturée, et la personne d’expérience qui vous a impressionné pendant la rencontre de vente est rarement celle qui écrit votre code. Demandez directement qui va le bâtir et si vous pouvez lui parler; la réponse vous dit quel risque vous achetez.
Il existe une troisième formule qui convient à la plupart des mandats de PME : une petite équipe où la personne au bout du fil est celle qui bâtit. Vous gardez le contact direct d’un développeur seul et la couverture d’une équipe — aucune couche de coordination à financer, aucun point de défaillance unique à craindre. C’est délibérément le modèle de VX-N, et c’est l’ère de l’IA qui permet à cette formule de fonctionner sur toute l’étendue du travail : une petite équipe expérimentée qui bâtit avec l’IA à chaque étape couvre maintenant le terrain — design, développement côté serveur, intégrations, livraison — qui justifiait autrefois une agence de douze personnes, à environ dix fois le rythme d’avant l’IA. L’ancienne raison d’accepter les frais généraux d’une agence, c’était que l’étendue exigeait des effectifs. Ce n’est plus le cas.
Peu importe votre choix, exigez que le premier jalon soit petit et que le code et les comptes soient à votre nom. Le petit jalon — un plan, une maquette, une démo fonctionnelle de la partie la plus risquée — est votre véritable entrevue : il vous montre sa rapidité, sa communication et à quoi ressemble son « terminé », tout en limitant votre exposition au prix d’un livrable plutôt que d’un projet entier. La clause de propriété n’est pas négociable et doit être écrite avant que l’argent change de mains : code source, hébergement, nom de domaine et clés d’API dans vos comptes dès le premier jour. Un fournisseur qui résiste à l’une ou l’autre de ces conditions vous annonce comment la relation va se passer.
Jugez les candidats sur les questions qu’ils posent, pas sur les promesses qu’ils font. Le fournisseur qui vous interroge sur votre processus avant de chiffrer — ce qui déclenche telle étape, qui y touche, ce qui arrive quand ça échoue — fait de l’ingénierie; celui qui donne un montant et une date à partir d’une description de deux lignes fait de la vente, et le vrai coût arrive plus tard sous forme de demandes de modification. De même, demandez ce qu’il refuserait de bâtir, et ce qui se passe après la livraison : qui répare l’intégration qui cesse de fonctionner au sixième mois, et si un développeur compétent peut reprendre le système à partir de la documentation. Un oui à cette dernière question, c’est la différence entre embaucher un bâtisseur et acquérir une dépendance.
Dernière révision le 28 août 2026