Comment choisir son agence de développement ? Les 8 questions a poser
Avant de signer un contrat a 50 000 euros ou plus avec une agence de développement, posez ces 8 questions. Les réponses vous diront si l'agence est compétente, fiable et alignée avec vos besoins reels.
Nos clients types
En 10 ans de direction d'agence chez Nehos, j'ai vu trop de clients arriver chez nous après un échec avec un prestataire precedent. Le schema est presque toujours le même : le projet a commence avec enthousiasme, les premiers sprints étaient prometteurs, puis les délais ont derape, la communication s'est dégradée et le code livre ne correspondait pas aux attentes.
Dans 90 % des cas, le problème aurait pu être detecte avant la signature du contrat en posant les bonnes questions. Cet article vous donne les 8 questions que tout décideur devrait poser avant de s'engager avec une agence de développement — et les réponses qui doivent vous alerter.
#Question 1 : Quelle stack technique proposez-vous et pourquoi ?
Cette question teste deux choses : la competence technique de l'agence et sa capacité a justifier ses choix en fonction de votre contexte, pas du sien.
Une bonne réponse : l'agence recommande une stack en fonction de vos contraintes (equipe existante, budget, besoins de performance, recrutement futur) et peut expliquer les alternatives qu'elle a écartées avec des arguments concrets. "On recommande Symfony pour votre projet parce que vous avez des workflows métier complexes et que votre equipe interne a déjà des competences PHP" — c'est une bonne réponse.
Une mauvaise réponse : l'agence recommande toujours la même stack quel que soit le projet, ou ne peut pas expliquer pourquoi elle a choisi une technologie plutôt qu'une autre. "On fait tout en [framework X] parce que c'est ce qu'on connaît" — c'est un red flag. L'agence optimise pour elle, pas pour vous.
Chez Nehos, on maitrise Symfony 7, Next.js 16, React 19, Payload CMS, Strapi et WordPress headless. On recommande la stack la plus adaptée au contexte du client, pas celle qui arrange notre planning.
#Question 2 : Pouvez-vous me montrer 3 references vérifiables sur des projets similaires ?
Les portfolios sont faciles a gonfler. Ce qui compte, ce sont des références client que vous pouvez contacter directement par téléphone ou par email pour poser vos propres questions.
Une bonne réponse : l'agence vous donne les noms et coordonnées de 3 clients dont les projets sont comparables au votre en termes de complexité, de stack technique et de taille de budget. Elle accepte que vous les contactiez sans être presente.
Une mauvaise réponse : l'agence montre de belles maquettes mais ne peut pas vous mettre en contact avec les clients. Ou elle ne peut pas montrer de projets dans votre domaine technique (par exemple, elle n'a jamais fait de projet Symfony mais vous recommande Symfony).
Les 3 questions a poser aux references : le projet a-t-il été livre dans les délais annonces ? Le budget final est-il reste dans la fourchette initiale ? Recommanderiez-vous cette agence a un collègue ?
Consultez nos cas clients pour voir des exemples concrets de projets livres par Nehos avec les résultats obtenus.
#Question 3 : Quel est votre process de gestion de projet ?
Cette question revele la maturité opérationnelle de l'agence. Une agence qui n'a pas de process défini improvisera sur votre projet — et l'improvisation sur un projet a 50 000 euros ou plus est un risque que vous ne devriez pas prendre.
Une bonne réponse : l'agence décrit un process structure avec des étapes claires. Par exemple : cadrage fonctionnel (1-2 semaines), wireframes et validation (1 semaine), sprints de développement de 2 semaines avec demo en fin de sprint, phase de recette et corrections, mise en production et accompagnement.
Une mauvaise réponse : "On est agiles, on s'adapte" sans pouvoir décrire concrètement comment se deroule un sprint, qui participe aux demos, a quelle fréquence le client a de la visibilité sur l'avancement.
Les points a verifier dans le process : fréquence des points d'avancement (minimum hebdomadaire), outils de suivi utilises (Jira, Linear, Notion), accès client au backlog et aux tickets, demo fonctionnelle en fin de sprint, process de validation avant passage en production.
#Question 4 : Quels sont vos engagements de service (SLA) ?
Les SLA (Service Level Agreements) sont les engagements mesurables de l'agence. Sans SLA, les promesses orales n'ont aucune valeur contractuelle.
Une bonne réponse : l'agence detaille ses SLA par catégorie. Par exemple : temps de réponse en cas de bug critique (4h ouvrables), temps de resolution des bugs non critiques (48h ouvrables), disponibilité garantie mensuelle pour la maintenance (nombre d'heures), fréquence des mises à jour de sécurité (mensuelle), temps de réponse pour les demandes d'évolution (48h pour le chiffrage).
Une mauvaise réponse : pas de SLA formalisée, ou des SLA vagues ("on répond rapidement"). Si l'agence ne peut pas s'engager sur des délais mesurables, elle n'a probablement pas les process internes pour les tenir.
Chez Nehos, nos SLA sont contractuels et mesures : 4h de temps de réponse pour les urgences critiques (P0), 24h pour les bugs fonctionnels (P1), 5 jours ouvrables pour les demandes d'évolution (P2). On fournit un rapport mensuel avec les métriques de respect des SLA.
#Question 5 : A qui appartient le code source ?
C'est la question la plus importante que beaucoup de clients oublient de poser. Si l'agence conserve la propriété du code source, vous êtes captif — changer de prestataire revient a recommencer de zero.
Une bonne réponse : "Le code source vous appartient intégralement des la livraison de chaque sprint. Vous avez un accès permanent au repository Git pendant et après le projet. La cession des droits de propriété intellectuelle est incluse dans le contrat."
Une mauvaise réponse : "Le code est notre propriété, vous avez une licence d'utilisation." Ou pire : "On vous donnera le code a la fin du projet." Dans le premier cas, vous êtes otage. Dans le second, si le projet echoue, vous n'avez rien.
Les points a verifier contractuellement : cession complete des droits de propriété intellectuelle sur le code spécifique (pas sur les frameworks open source évidemment), accès Git permanent pendant le développement, clause de transfert de code en cas de résiliation du contrat, documentation technique suffisante pour permettre une reprise par un tiers.
Chez Nehos, le client est propriétaire du code des le premier commit. On lui donne l'accès au repository Git des le jour 1 du projet, et le contrat inclut une clause de cession de PI complete.
#Question 6 : Que proposez-vous comme TMA après la livraison ?
La livraison n'est pas la fin du projet — c'est le debut de la phase la plus longue : la maintenance. Un site web ou une application necessite des mises à jour de sécurité, des corrections de bugs, des évolutions fonctionnelles et un monitoring continu.
Une bonne réponse : l'agence propose un contrat de TMA (Tierce Maintenance Applicative) avec un volume d'heures mensuelles, des SLA de temps de réponse, un rapport mensuel d'activité et une equipe dédiée (au minimum 2 développeurs qui connaissent la codebase).
Une mauvaise réponse : "On verra ca après la livraison" ou "On facture au temps passe sans engagement." L'absence de TMA structurée signifie que vous dépendrez de la bonne volonté de l'agence — qui sera probablement occupée sur de nouveaux projets.
Le coût raisonnable d'une TMA en France en 2026 : entre 500 et 2 000 euros par mois pour un site vitrine, entre 1 500 et 5 000 euros par mois pour une application métier, entre 3 000 et 10 000 euros par mois pour une plateforme complexe. Ce budget couvre les mises à jour de sécurité, les corrections de bugs, le monitoring et un volume d'évolutions mineures.
En savoir plus sur notre offre TMA avec les details de nos forfaits et SLA.
#Question 7 : Pouvez-vous scaler l'equipe si le projet grandit ?
Un projet web commence souvent avec un périmètre défini, puis s'étend a mesure que le produit rencontre son marche. L'agence doit pouvoir accompagner cette croissance sans que le client ait a changer de prestataire.
Une bonne réponse : l'agence explique sa capacité d'absorption. Par exemple : "Notre equipe de 50 développeurs nous permet de passer de 2 à 6 développeurs sur votre projet en 2 a 4 semaines. On a un vivier de freelances identifies et testes pour les besoins ponctuels." L'agence peut nommer les profils qu'elle pourrait mobiliser.
Une mauvaise réponse : l'agence est une equipe de 3 à 5 personnes qui sera saturée si votre projet grossit. Ce n'est pas un défaut en soi (les petites agences font d'excellent travail), mais il faut être lucide : si le projet double de périmètre, cette agence ne pourra pas suivre et vous devrez en chercher une deuxième en parallèle.
Chez Nehos, notre equipe de 50 experts nous permet de scaler rapidement. On a des profils spécialisés en Symfony, Next.js, React, DevOps, design UI/UX et data/IA que l'on peut mobiliser en fonction des besoins du projet.
#Question 8 : Comment facturez-vous — forfait, régie ou hybride ?
Le modèle de tarification impacte directement la relation client-agence. Aucun modèle n'est universellement meilleur — chacun a ses avantages selon le contexte.
Le forfait (prix fixe pour un périmètre défini) convient quand le cahier des charges est stable et detaille. L'avantage : prévisibilité budgétaire. Le risque : l'agence rogne sur la qualité si le forfait est trop serre, ou le client paie des avenants pour chaque changement de périmètre.
La régie (facturation au temps passe) convient quand le projet evolue en cours de route et que le périmètre n'est pas fige. L'avantage : flexibilité totale. Le risque : le budget peut déraper si le suivi n'est pas rigoureux.
L'hybride (forfait pour le cadrage et les livrables principaux, régie pour les évolutions) est souvent le modèle le plus equilibre. Le client a une enveloppe budgétaire prévisible pour le coeur du projet et de la flexibilité pour les ajustements.
Une bonne réponse : l'agence explique ses 2 a 3 modèles de tarification, recommande celui qui convient à votre contexte et detaille les conditions (TJM en régie, périmètre en forfait, conditions de l'hybride).
Une mauvaise réponse : l'agence ne propose qu'un seul modèle ou ne peut pas détailler ses conditions de facturation. Méfiez-vous aussi des devis forfaitaires très bas qui seront rattrapes par des avenants.
Chez Nehos, on propose les 3 modèles. Pour les projets de plus de 30 000 euros, on recommande généralement l'hybride : forfait pour le cadrage, les wireframes et l'architecture (phase 1), puis régie pour les sprints de développement (phase 2) avec un budget enveloppe et un suivi hebdomadaire.
Consultez nos tarifs pour voir nos grilles TJM et nos modèles de facturation en detail.
#Les red flags qui doivent vous faire fuir
L'agence ne peut pas nommer les développeurs qui travailleront sur votre projet. Vous ne savez pas qui écrit le code de votre application — c'est inacceptable.
L'agence ne donne pas d'accès Git pendant le développement. Le code est votre propriété. Si l'agence le garde en otage, c'est un signal clair de pratiques contractuelles abusives.
Le premier rendez-vous est uniquement commercial, sans aucun technique present. Si l'agence ne peut pas répondre à vos questions techniques des le premier echange, le commercial vendra des promesses que l'equipe technique ne pourra pas tenir.
L'agence sous-traite sans le dire. Demandez directement : "Est-ce que vous sous-traitez une partie du développement ?" La sous-traitance n'est pas un problème en soi si elle est transparente et encadrée — mais la sous-traitance cachée est un red flag majeur.
Pas de demo régulière. Si l'agence ne propose pas de demo fonctionnelle en fin de sprint (toutes les 2 semaines), vous n'aurez de visibilité sur le projet qu'a la livraison finale — et il sera trop tard pour corriger les écarts.
#La checklist finale avant de signer
Avant de signer le contrat avec l'agence retenue, vérifiez ces 12 points.
- Le contrat inclut la cession complete de propriété intellectuelle sur le code.
- L'accès Git est garanti pendant le développement et après la livraison.
- Les développeurs nommes sont identifies et leurs profils LinkedIn sont cohérents avec l'expertise annoncée.
- Les SLA sont contractuels et mesurables (temps de réponse, délais de resolution).
- Un contrat de TMA est propose avec des modalités claires (volume d'heures, tarif, SLA).
- Le process de gestion de projet est documente et prévoit des demos régulières.
- Les conditions de résiliation sont raisonnables (préavis, transfert de code, documentation).
- Les references clients sont vérifiées (vous avez appelé au minimum 2 clients precedents).
- Le modèle de tarification est adapte à votre contexte (forfait, régie ou hybride).
- La stack technique est justifiée par des arguments lies à votre projet, pas a l'agence.
- L'agence a une assurance RC Pro et un capital social suffisant.
- Le périmètre fonctionnel est detaille dans un document signe par les deux parties.
Si 10 ou plus de ces 12 points sont coches, vous avez probablement un bon prestataire. En dessous de 8, reconsidérez votre choix.
Questions frequentes : choisir son agence de développement
La bonne pratique est de consulter 3 a 5 agences pour un projet de plus de 30 000 euros. Moins de 3, vous n'avez pas assez de points de comparaison. Plus de 5, vous perdez du temps sans gain de qualité de décision. Pour chaque agence, prévoyez un premier rendez-vous de découverte (30 a 60 minutes), puis un rendez-vous technique approfondi (1 a 2 heures) avec les profils qui travailleront sur le projet. Évaluez les agences sur les 8 critères de cet article avec un système de notation (1 a 5 par critère) pour objectiver la comparaison. Le coût de ce processus de selection est de 2 à 4 semaines — un investissement négligeable par rapport au risque de choisir le mauvais prestataire sur un projet a 6 chiffres.
Oui, mais pas comme on le croit. Une agence de 5 personnes peut livrer un excellent travail sur un projet a 40 000 euros. Mais elle ne pourra pas scaler si le projet double de périmètre, et le risque de Bus Factor est eleve (si 1 des 2 développeurs part, le projet s'arrete). Une agence de 200 personnes a la capacité de scalabilite mais le risque de turnover est plus eleve et le client peut se sentir noyé dans un grand compte. Le sweet spot pour les projets PME et ETI est généralement une agence de 20 à 80 personnes : assez grande pour avoir des process solides, un vivier de profils et une capacité de scalabilite, mais assez petite pour maintenir une relation client directe et un engagement personnel des fondateurs. Chez Nehos, avec 50 experts, on se situe dans cette zone.
En 2026, la proximité géographique est moins déterminante qu'en 2020. La majorité des agences travaillent en mode hybride (remote + reunions presentielles ponctuelles). Les outils de collaboration (Slack, Notion, Figma, Loom) permettent une communication efficace à distance. Cependant, 2 a 3 reunions presentielles restent utiles : le kick-off projet pour aligner les equipes, la recette finale pour valider les livrables, et éventuellement une demo intermédiaire pour les projets longs. Pour un projet de plus de 50 000 euros, on recommande une agence accessible pour ces reunions clés — dans un rayon de 2h de trajet. Nehos est basée à Toulouse et intervient sur tout le territoire français, avec des reunions presentielles a la demande du client.
Quatre méthodes complémentaires. Premiere méthode : demandez un audit technique d'un code existant (le votre ou un projet open source). L'agence qui peut identifier des problèmes concrets dans un code demontre une expertise réelle. Deuxième méthode : posez des questions techniques spécifiques à votre stack lors du rendez-vous technique. Un développeur senior doit pouvoir expliquer les différences entre Symfony et Laravel, ou entre SSR et SSG, sans jargon et avec des exemples concrets. Troisième méthode : vérifiez les contributions open source de l'equipe (profils GitHub). Quatrième méthode : demandez les certifications et formations récentes de l'equipe. Une agence qui investit dans la formation continue de ses développeurs est une agence qui prend la qualité au sérieux.