Comment choisir un développeur ou une agence pour votre entreprise

Engager un développeur ou une agence est l'une des décisions les plus risquées qu'un propriétaire d'entreprise prend, et la plupart des gens y vont sans aucun cadre d'évaluation. Vous n'engageriez pas un comptable sans vérifier ses qualifications, ni un entrepreneur sans voir ses travaux précédents. Pourtant je rencontre régulièrement des propriétaires d'entreprise qui ont engagé le premier développeur trouvé sur Upwork, payé 50 % d'avance sans contrat, et se sont retrouvés avec un produit à moitié fini qu'ils ne peuvent ni utiliser ni maintenir.

Je vais vous donner la perspective de l'intérieur — les choses que les développeurs savent sur l'industrie et que les clients apprennent généralement à leurs dépens.

Freelance vs. Agence vs. Interne : les compromis

Avant de commencer à évaluer des candidats individuels, vous devez décider quel type d'engagement a du sens pour votre projet.

Développeurs freelance

Idéal pour : Projets petits à moyens avec un périmètre bien défini, maintenance continue de produits existants, ajout de fonctionnalités spécifiques à un codebase existant.

Coût typique : 50-200 $/heure selon l'expérience et la localisation, ou 3 000-30 000 $ par projet.

Avantages : Des frais généraux plus bas signifient des coûts plus bas. Vous travaillez directement avec la personne qui construit votre produit — pas de chefs de projet, de commerciaux ou de couches de communication intermédiaires. Les bons freelances sont très réactifs parce que leur réputation dépend de chaque projet.

Inconvénients : Point de défaillance unique. Si votre freelance tombe malade, part en vacances ou prend trop de projets, votre calendrier glisse. Capacité limitée pour les grands projets. Pas de capacités intégrées en design, QA ou DevOps — vous pourriez avoir besoin d'engager plusieurs freelances et de les coordonner vous-même.

La réalité : L'éventail de qualité parmi les freelances est énorme. Les meilleurs freelances sont meilleurs que la plupart des équipes d'agences et facturent en conséquence. Les pires prendront votre argent et livreront du code inutilisable. Votre travail est de les distinguer (plus de détails ci-dessous).

Agences

Idéal pour : Projets moyens à grands nécessitant plusieurs disciplines (design, frontend, backend, mobile), entreprises qui ont besoin d'une équipe sans embaucher à temps plein, projets où vous voulez un seul point de responsabilité.

Coût typique : 100-300 $/heure pour l'équipe, ou 20 000-200 000+ $ par projet.

Avantages : Vous obtenez une équipe — designer, développeurs, chef de projet, QA — sans en embaucher aucun. Les bonnes agences ont des processus établis, des standards de qualité et des structures de responsabilité. Elles peuvent gérer des projets plus grands et adapter la taille de l'équipe selon les besoins.

Inconvénients : Coût plus élevé car vous payez les frais généraux (bureaux, management, commercial, marketing). La communication passe souvent par un chef de projet, ce qui ajoute une couche entre vous et les personnes qui font le travail. Certaines agences priorisent le revenu sur la qualité et recommanderont plus de travail que nécessaire.

La réalité : La qualité des agences varie autant que celle des freelances, juste à un prix plus élevé. Les meilleures agences délivrent un travail systématiquement excellent avec une gestion de projet professionnelle. Les pires facturent des tarifs d'agence puis sous-traitent le développement réel à des prestataires bon marché à l'étranger sans vous le dire. Demandez qui écrira réellement le code.

Développeurs internes

Idéal pour : Les entreprises où la technologie est le produit principal, les entreprises avec des besoins de développement continus qui coûteraient plus cher à externaliser, les organisations qui ont besoin d'une attention dédiée à temps plein.

Coût typique : 80 000-180 000 $/an de salaire plus avantages, espace de bureau, équipement et frais de management. Le coût réel est généralement 1,3-1,5 fois le salaire.

Avantages : Dédication à temps plein à votre projet. Compréhension profonde de votre entreprise au fil du temps. Pas de surprises de facturation. Vous possédez la relation et le savoir.

Inconvénients : L'embauche prend 2-4 mois. Vous devez en savoir assez sur la technologie pour évaluer les candidats et les gérer efficacement (ou embaucher quelqu'un qui le fait). Vous êtes responsable de leur développement de carrière, de les garder engagés et de les remplacer s'ils partent. Un seul développeur ne peut pas couvrir toutes les technologies — vous pourriez toujours avoir besoin de prestataires pour des travaux spécialisés.

La réalité : L'interne n'a de sens que quand vos besoins de développement continus sont assez importants pour occuper un développeur à temps plein. Si vous avez besoin de 20 heures de développement par mois, embaucher un développeur à temps plein à 150 000 $/an signifie que vous payez 625 $/heure pour leur temps utilisé. Un freelance à 150 $/heure coûterait une fraction de cela.

Ma recommandation

Pour la plupart des petites et moyennes entreprises construisant leur premier produit numérique, commencez par un freelance ou une petite agence pour le développement initial. Ne passez à l'interne que quand votre produit génère assez de revenus pour justifier des salaires à temps plein et que vos besoins de développement sont continus (pas basés sur des projets).

Si votre projet est assez complexe pour nécessiter une équipe (application mobile + backend + tableau de bord web, par exemple), une petite agence (5-15 personnes) fournit généralement le meilleur équilibre entre qualité, coordination et coût. Les grandes agences (50+ personnes) sont meilleures pour les projets à l'échelle de l'entreprise où vous avez besoin de ressources profondes dans des domaines spécialisés.

Comment évaluer un portfolio

Un portfolio est l'outil d'évaluation le plus important dont vous disposez, mais la plupart des gens le regardent mal. Ils voient de jolies captures d'écran et supposent la qualité. Voici ce qu'il faut vraiment chercher.

Visitez les sites en ligne

Ne vous contentez pas de regarder des captures d'écran dans une présentation de portfolio. Demandez des URL et visitez réellement les sites ou téléchargez les applications. Un nombre surprenant de « pièces de portfolio » ne sont plus en ligne, ce qui signifie soit que le client a fermé (ça arrive), soit que le projet n'a jamais été terminé (signal d'alerte), soit que la qualité s'est détériorée après le lancement parce que personne ne l'a maintenu (questions sur la qualité à long terme).

Quand vous visitez un site en ligne, faites attention à :

• La vitesse. Se charge-t-il rapidement sur votre téléphone ? Essayez-le sur une connexion cellulaire, pas votre Wi-Fi de bureau. Si la propre pièce de portfolio d'un développeur est lente, qu'est-ce que cela dit des standards qu'il applique au travail client ?
• L'expérience mobile. Ouvrez-le sur votre téléphone. Est-il utilisable ? Pouvez-vous trouver l'information sans difficulté ? Les boutons sont-ils faciles à taper ?
• Le soin du détail. Les images se chargent-elles correctement ? Y a-t-il des liens cassés ? Le texte est-il bien formaté ? Ces détails révèlent le niveau de soin que le développeur apporte à un projet.

Demandez quel était leur rôle

Quand un développeur ou une agence vous montre un projet, demandez : « Qu'avez-vous construit spécifiquement ? » Beaucoup de portfolios incluent des projets où le développeur a construit une petite partie d'un système plus large, ou où il a personnalisé un template plutôt que de construire à partir de zéro. Aucun de ces cas n'est intrinsèquement mauvais, mais vous devez comprendre l'étendue de leur contribution pour évaluer si leurs compétences correspondent à vos besoins.

Cherchez des projets similaires au vôtre

Un développeur qui a construit cinq boutiques e-commerce construira une sixième meilleure qu'un développeur qui n'en a jamais construit. L'expérience du domaine compte — pas parce que la technologie est différente, mais parce que les développeurs expérimentés ont déjà fait et appris des erreurs que les développeurs inexpérimentés feront sur votre projet.

Cela ne signifie pas que vous devriez engager uniquement quelqu'un qui a construit une réplique exacte de ce que vous voulez. Mais si votre projet est un système de commande pour restaurant, un développeur qui a construit des produits food-tech comprendra les cas limites (personnalisation de menu, zones de livraison, workflows de cuisine, partage de l'addition) qu'un développeur qui n'a fait que des sites marketing ne comprendra pas.

Vérifiez les dates

Demandez quand les projets du portfolio ont été réalisés. Le développement web évolue vite. Un portfolio rempli de projets de 2019 qui n'ont pas été mis à jour depuis vous dit quelque chose sur le niveau d'activité actuel du développeur et la qualité à long terme de son travail. Les projets récents (dans les 12-18 derniers mois) sont plus pertinents pour évaluer les compétences actuelles.

Signaux d'alerte qui devraient vous faire fuir

Au fil de mes années dans cette industrie, j'ai vu toutes les variantes de projets qui tournent mal. Voici les signes d'avertissement qui, d'après mon expérience, prédisent systématiquement l'échec.

Le prix est suspicieusement bas

Si un développeur devis 15 000 $, un autre 12 000 $, et un troisième 2 000 $ pour le même projet, le développeur à 2 000 $ n'est pas plus efficace — il coupe des coins que vous ne pouvez pas encore voir, prévoit de vous facturer des avenants plus tard, ou ne comprend tout simplement pas l'étendue de ce que vous demandez.

L'option la plus chère n'est pas toujours la meilleure, mais la moins chère n'est presque jamais la meilleure. Le développement de qualité prend du temps, et le temps coûte de l'argent. Quand quelqu'un sous-cote significativement le marché, il y a toujours une raison.

Pas de processus ni de méthodologie

Un bon développeur ou une bonne agence devrait pouvoir vous décrire leur processus avant que vous ne signiez quoi que ce soit. À quoi ressemble la phase de découverte ? Comment recueilleront-ils les exigences ? Quand verrez-vous les maquettes ? Comment donnerez-vous vos retours ? À quelle fréquence recevrez-vous des mises à jour de progression ? Que se passe-t-il quand quelque chose doit changer ?

Si la réponse est « dites-moi juste ce que vous voulez et je le construirai », vous allez vers un projet où les attentes sont décalées, les délais sont flous et les conflits sont inévitables. Le processus n'est pas de la bureaucratie — c'est la façon dont les professionnels expérimentés gèrent la complexité et délivrent des résultats prévisibles.

Ils ne mentionnent pas les tests

Demandez comment ils testent leur travail. Si la réponse est « je le teste moi-même avant de le livrer » sans mention de tests systématiques, de processus d'assurance qualité ou de tests sur plusieurs appareils et navigateurs, votre produit sera livré avec des bugs. Chaque produit a des bugs, mais la différence entre un développeur professionnel et un amateur est si ces bugs sont détectés avant ou après que vos clients les trouvent.

Les bons développeurs écrivent des tests automatisés qui vérifient que leur code fonctionne correctement. Ils testent sur plusieurs navigateurs et appareils. Ils font vérifier par quelqu'un d'autre que la personne qui a écrit le code. Ces pratiques coûtent du temps, ce qui fait partie de la raison pour laquelle le développement de qualité coûte plus que le développement amateur.

Résistance aux contrats ou à la documentation

Si un développeur résiste à avoir un contrat écrit, c'est un signal d'alerte majeur. Les professionnels accueillent les contrats parce que les contrats protègent les deux parties. Un contrat devrait couvrir : le périmètre de travail, le calendrier, l'échéancier de paiement, la propriété intellectuelle, ce qui se passe si le périmètre change, et comment chaque partie peut mettre fin à l'engagement.

De même, s'ils résistent à documenter les décisions techniques ou à créer de la documentation sur le fonctionnement de votre système, vous construisez une dépendance envers cette personne spécifique. Quand elle n'est pas disponible (ou que vous voulez changer de développeur), l'absence de documentation signifie que la personne suivante doit tout rétro-ingéniérer à partir de zéro.

Ils promettent des délais irréalistes

« Je peux construire toute votre plateforme en deux semaines. » Non, ils ne peuvent pas. Pas bien, en tout cas. Le développement logiciel sur mesure prend du temps parce que les parties les plus difficiles — comprendre les exigences, gérer les cas limites, tester, itérer sur les retours — ne peuvent pas être compressées.

Un développeur qui promet un calendrier agressif prévoit soit de couper des coins, soit ne comprend pas le périmètre, soit reviendra en semaine deux avec une liste de « complications » qui étendent le calendrier (et le budget) significativement.

Essentiels du contrat : ce qui devrait figurer dans l'accord

Que vous engagiez un freelance ou une agence, l'accord écrit devrait couvrir ces domaines.

Périmètre de travail

Le périmètre devrait décrire ce qui sera construit avec assez de détails pour que les deux parties puissent regarder le produit fini et s'accorder sur le fait qu'il correspond à ce qui a été promis. Pas si détaillé que chaque pixel est spécifié (ce niveau de rigidité fait échouer les projets), mais assez détaillé pour que « construisez-moi un site web » ne devienne pas un désaccord sur l'inclusion d'un système de réservation.

Je recommande un document de périmètre qui décrit les fonctionnalités en termes de résultats utilisateur : « Un client peut parcourir le menu, ajouter des articles au panier et passer commande par carte de crédit » est plus clair que « fonctionnalité e-commerce ».

Structure de paiement

Ne payez jamais 100 % d'avance. Une structure de paiement par jalons aligne les intérêts et protège les deux parties.

Une structure courante qui fonctionne bien :

• 20-30 % d'avance pour démarrer le projet (couvre le risque du développeur de commencer le travail)
• 30-40 % à mi-parcours (typiquement après l'approbation du design ou un prototype fonctionnel)
• 30-40 % à la livraison (après la revue finale et le déploiement)

Pour les projets plus importants, vous pourriez avoir 4-5 jalons. La clé est que chaque paiement est lié à un livrable que vous pouvez évaluer. Si le projet stagne, vous n'avez payé que le travail réalisé jusque-là.

Horaire vs. prix fixe : Les contrats à prix fixe fonctionnent bien quand le périmètre est clairement défini. Les contrats horaires fonctionnent mieux pour les projets dont le périmètre va évoluer ou où vous voulez de la flexibilité pour ajuster les priorités. Beaucoup de développeurs expérimentés préfèrent la facturation horaire parce qu'elle est plus honnête — les contrats à prix fixe incluent souvent des primes de risque qui gonflent le coût total.

Propriété intellectuelle

C'est la clause que la plupart des fondateurs non techniques négligent puis regrettent. Vous devriez posséder le code écrit pour votre projet. Cela devrait être explicite dans le contrat.

Il y a des nuances. La plupart des développeurs utilisent des bibliothèques open-source, des frameworks et parfois leurs propres composants pré-construits dans votre projet. Vous ne possédez pas ceux-là — ils sont licenciés sous leurs propres termes. Ce que vous devriez posséder, c'est le code sur mesure écrit spécifiquement pour votre projet et les assets de design créés pour vous.

Sans clause de PI claire, le développeur possède techniquement le code et vous le licence. Cela crée une dépendance : si la relation se termine mal, il pourrait argumenter que vous n'avez pas le droit de modifier ou maintenir le code.

Considérations NDA

Si votre projet implique une logique métier propriétaire, des données clients ou une idée véritablement nouvelle, un accord de non-divulgation est raisonnable. La plupart des développeurs professionnels signeront un NDA standard sans objection.

Cependant, comprenez ce qu'un NDA fait et ne fait pas. Il protège les informations confidentielles — pas les idées. Si votre concept d'entreprise est « Uber pour la promenade de chiens », un NDA n'empêche pas quelqu'un de construire un produit concurrent. Il empêche de partager les détails d'affaires spécifiques, les données clients et les processus propriétaires que vous avez divulgués pendant l'engagement.

Gardez les NDA raisonnables en portée et en durée. Un NDA de 2 ans couvrant les informations partagées pendant le projet est standard. Un NDA de 10 ans qui empêche le développeur de travailler dans toute votre industrie est déraisonnable et un bon développeur le repoussera (à juste titre).

Évaluation technique pour les fondateurs non techniques

Vous n'avez pas besoin de comprendre le code pour évaluer un partenaire technique. Voici une checklist que vous pouvez utiliser.

Demandez pourquoi ces choix technologiques

Un bon développeur expliquera ses recommandations technologiques en termes compréhensibles et les justifiera en fonction des besoins de votre projet — pas de ses préférences personnelles. Demandez : « Pourquoi recommandez-vous cette technologie pour mon projet ? » La réponse devrait faire référence à vos exigences spécifiques, votre calendrier et votre budget.

Méfiez-vous des développeurs qui recommandent la technologie la plus récente et la plus à la pointe pour un site web professionnel standard. Les technologies éprouvées et matures sont presque toujours le meilleur choix pour les applications d'entreprise. Les nouveaux outils sont excitants pour les développeurs mais risqués pour votre projet.

Demandez concernant l'hébergement et le déploiement

Où vivra votre site web ou application ? Qui gère les serveurs ? Que se passe-t-il si le site tombe à 2h du matin ? Comment les mises à jour sont-elles déployées ?

Vous devriez comprendre l'arrangement d'hébergement suffisamment pour savoir : qui est responsable de le maintenir en fonctionnement, quel est le coût mensuel, et si vous pouvez passer à un autre fournisseur si nécessaire. Si le développeur héberge tout sur son serveur personnel et que vous n'avez pas d'accès, vous êtes enfermé dans cette relation — et exclu de votre propre produit.

Demandez concernant la sécurité

Pour tout projet qui gère des données clients ou des paiements, demandez comment ils gèrent la sécurité. La réponse n'a pas besoin d'être profondément technique, mais elle devrait couvrir : comment les données clients sont stockées et protégées, comment les paiements sont traités (ils devraient utiliser des processeurs de paiement établis comme Stripe, pas gérer directement les numéros de carte), si le site utilise HTTPS, et comment les identifiants d'accès sont gérés.

S'ils rejettent les questions de sécurité comme sans importance pour votre projet, c'est un signal d'alerte. La sécurité est importante pour chaque projet qui a des utilisateurs.

Demandez des références

C'est l'outil d'évaluation le plus sous-utilisé. Demandez 2-3 références de clients passés — de préférence des clients avec des projets similaires en taille et en type au vôtre. Puis appelez-les réellement.

Questions à poser aux références :

• Le projet a-t-il été terminé dans les temps et le budget ?
• Comment était la communication pendant le projet ?
• Y a-t-il eu des surprises ou des coûts imprévus ?
• Les engageriez-vous à nouveau ?
• Comment gèrent-ils les problèmes ou les désaccords ?

Les réponses vous en diront plus que n'importe quelle revue de portfolio ou appel commercial.

Gérer la relation pour la réussite du projet

Engager le bon développeur est la moitié de la bataille. Gérer l'engagement efficacement est l'autre moitié.

Fixez les attentes de communication tôt

Avant le début du travail, convenez de :

• La fréquence de communication (mises à jour hebdomadaires au minimum)
• Le canal (email, Slack, un outil de gestion de projet)
• Les attentes de temps de réponse (24 heures pour les questions non urgentes, le jour même pour les blocages)
• Des points réguliers (un appel vidéo hebdomadaire de 30 minutes pour passer en revue l'avancement)

La plupart des échecs de projet que j'ai vus n'ont pas été causés par un mauvais développement — ils ont été causés par des ruptures de communication. Le développeur a construit quelque chose de différent de ce que le client voulait parce qu'aucune des parties n'a vérifié l'alignement avant qu'il ne soit trop tard.

Donnez des retours clairs et écrits

Quand vous revoyez un travail en cours, mettez vos retours par écrit. « Je n'aime pas le design » est inutile. « La police du header semble trop décontractée pour notre marque — pouvons-nous utiliser quelque chose de plus professionnel, similaire à ce qu'on voit sur [exemple spécifique] ? » donne au développeur quelque chose d'actionnable.

Créez un document partagé ou utilisez un outil de gestion de projet où les retours sont suivis et traités. Les retours verbaux en appel sont oubliés. Les retours écrits créent de la responsabilité et une trace de référence.

Gérez les changements de périmètre de manière délibérée

Chaque projet rencontre des changements de périmètre. Une nouvelle idée de fonctionnalité, un changement dans les exigences métier, ou des retours d'utilisateurs précoces — c'est normal et sain. Le problème survient quand les changements de périmètre arrivent de manière informelle, sans discuter de leur impact sur le calendrier et le budget.

Quand vous voulez ajouter ou changer quelque chose, formulez-le comme : « J'aimerais ajouter X. Comment cela affecte-t-il le calendrier et le coût ? » Cela force une conversation explicite sur les compromis. Le développeur pourrait dire que cela ajoute deux semaines et 3 000 $, et vous pouvez décider si ça vaut le coup. Ou il pourrait suggérer une version plus simple de la fonctionnalité qui rentre dans le périmètre existant. La clé est de rendre les changements de périmètre délibérés, pas accidentels.

Définissez « terminé » avant de commencer

La source la plus courante de conflit dans les projets de développement est le désaccord sur le moment où le projet est terminé. Le développeur pense avoir livré tout ce qui a été convenu. Le client attendait plus. Les deux agissent de bonne foi, mais leurs attentes n'ont jamais été alignées.

Avant le début du travail, créez un document de critères d'acceptation qui décrit — en langage simple — ce que le produit fini fera et comment vous le vérifierez. « Le processus de paiement fonctionne correctement » est vague. « Un client peut ajouter des articles au panier, entrer son adresse de livraison, payer par carte de crédit et recevoir un email de confirmation de commande » est testable.

Quand le livrable répond aux critères d'acceptation, le projet est terminé. Les modifications supplémentaires au-delà de ces critères sont un nouveau périmètre, avec leur propre calendrier et budget.

Après le projet : la suite

La passation à la fin d'un projet est aussi importante que le coup d'envoi au début.

Obtenez l'accès à tout. Login du registrar de domaine, compte d'hébergement, dépôt de code source, tous les comptes de services tiers (analytics, service email, processeur de paiement). Vous devriez pouvoir fonctionner de manière indépendante si la relation avec le développeur se termine. Si vous n'avez pas l'accès administrateur à chaque service dont votre produit dépend, vous n'avez pas le contrôle.

Obtenez de la documentation. Au minimum, vous avez besoin d'un document qui explique : comment mettre à jour le contenu, où le code se trouve, comment déployer les changements, quels services tiers le produit utilise, et les tâches de maintenance continues (comme le renouvellement des certificats SSL ou la mise à jour des dépendances).

Discutez de la maintenance continue. Chaque produit numérique nécessite une attention continue — correctifs de sécurité, mises à jour de dépendances, corrections de bugs, améliorations mineures basées sur les retours utilisateurs. Convenez d'un arrangement de maintenance : heures de provision, temps de réponse pour les urgences, et comment les demandes de maintenance seront priorisées.

Planifiez le transfert de connaissances. Si vous changez un jour de développeur (et sur un horizon assez long, vous le ferez probablement), le nouveau développeur doit comprendre ce qui a été construit et pourquoi. Une bonne documentation, du code propre et un codebase bien organisé rendent cette transition fluide. Une documentation pauvre et du code désordonné la rendent douloureuse et coûteuse.

L'état d'esprit d'investissement

Engager un développeur n'est pas un achat — c'est un investissement. Comme tout investissement, le retour dépend de bonnes décisions sur l'allocation de vos ressources et d'une gestion active du processus.

Le développeur le moins cher est rarement le meilleur rapport qualité-prix. Le plus cher n'est pas toujours le meilleur non plus. Le meilleur rapport qualité-prix vient de trouver un professionnel compétent qui comprend vos objectifs d'entreprise, communique clairement et livre de manière fiable.

Prenez le processus d'évaluation au sérieux. Vérifiez les références. Lisez le contrat attentivement. Fixez des attentes claires. Gérez la relation activement. L'effort initial que vous mettez dans le choix et la gestion du bon partenaire technique portera ses fruits pendant des années.

Et si quelque chose semble louche pendant le processus d'évaluation — si la communication est difficile, les réponses sont évasives ou les promesses semblent trop belles — fiez-vous à cette intuition. Le meilleur moment pour s'éloigner d'un mauvais partenaire de développement est avant de lui avoir donné votre argent.