Comment choisir son agence de developpement ? Les 8 questions a poser

En 10 ans de direction d'agence chez Nehos, j'ai vu trop de clients arriver chez nous apres un echec avec un prestataire precedent. Le schema est presque toujours le meme : le projet a commence avec enthousiasme, les premiers sprints etaient prometteurs, puis les delais ont derape, la communication s'est degradee et le code livre ne correspondait pas aux attentes.

Dans 90 % des cas, le probleme aurait pu etre detecte avant la signature du contrat en posant les bonnes questions. Cet article vous donne les 8 questions que tout decideur devrait poser avant de s'engager avec une agence de developpement — et les reponses 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 capacite a justifier ses choix en fonction de votre contexte, pas du sien.

Une bonne reponse : 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 ecartees avec des arguments concrets. "On recommande Symfony pour votre projet parce que vous avez des workflows metier complexes et que votre equipe interne a deja des competences PHP" — c'est une bonne reponse.

Une mauvaise reponse : l'agence recommande toujours la meme stack quel que soit le projet, ou ne peut pas expliquer pourquoi elle a choisi une technologie plutot qu'une autre. "On fait tout en [framework X] parce que c'est ce qu'on connait" — 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 adaptee au contexte du client, pas celle qui arrange notre planning.

#Question 2 : Pouvez-vous me montrer 3 references verifiables sur des projets similaires ?

Les portfolios sont faciles a gonfler. Ce qui compte, ce sont des references client que vous pouvez contacter directement par telephone ou par email pour poser vos propres questions.

Une bonne reponse : l'agence vous donne les noms et coordonnees de 3 clients dont les projets sont comparables au votre en termes de complexite, de stack technique et de taille de budget. Elle accepte que vous les contactiez sans etre presente.

Une mauvaise reponse : 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 ete livre dans les delais annonces ? Le budget final est-il reste dans la fourchette initiale ? Recommanderiez-vous cette agence a un collegue ?

Consultez nos cas clients pour voir des exemples concrets de projets livres par Nehos avec les resultats obtenus.

#Question 3 : Quel est votre process de gestion de projet ?

Cette question revele la maturite operationnelle de l'agence. Une agence qui n'a pas de process defini 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 reponse : l'agence decrit un process structure avec des etapes claires. Par exemple : cadrage fonctionnel (1-2 semaines), wireframes et validation (1 semaine), sprints de developpement de 2 semaines avec demo en fin de sprint, phase de recette et corrections, mise en production et accompagnement.

Une mauvaise reponse : "On est agiles, on s'adapte" sans pouvoir decrire concretement comment se deroule un sprint, qui participe aux demos, a quelle frequence le client a de la visibilite sur l'avancement.

Les points a verifier dans le process : frequence des points d'avancement (minimum hebdomadaire), outils de suivi utilises (Jira, Linear, Notion), acces 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 reponse : l'agence detaille ses SLA par categorie. Par exemple : temps de reponse en cas de bug critique (4h ouvrables), temps de resolution des bugs non critiques (48h ouvrables), disponibilite garantie mensuelle pour la maintenance (nombre d'heures), frequence des mises a jour de securite (mensuelle), temps de reponse pour les demandes d'evolution (48h pour le chiffrage).

Une mauvaise reponse : pas de SLA formalisee, ou des SLA vagues ("on repond rapidement"). Si l'agence ne peut pas s'engager sur des delais mesurables, elle n'a probablement pas les process internes pour les tenir.

Chez Nehos, nos SLA sont contractuels et mesures : 4h de temps de reponse pour les urgences critiques (P0), 24h pour les bugs fonctionnels (P1), 5 jours ouvrables pour les demandes d'evolution (P2). On fournit un rapport mensuel avec les metriques 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 propriete du code source, vous etes captif — changer de prestataire revient a recommencer de zero.

Une bonne reponse : "Le code source vous appartient integralement des la livraison de chaque sprint. Vous avez un acces permanent au repository Git pendant et apres le projet. La cession des droits de propriete intellectuelle est incluse dans le contrat."

Une mauvaise reponse : "Le code est notre propriete, vous avez une licence d'utilisation." Ou pire : "On vous donnera le code a la fin du projet." Dans le premier cas, vous etes otage. Dans le second, si le projet echoue, vous n'avez rien.

Les points a verifier contractuellement : cession complete des droits de propriete intellectuelle sur le code specifique (pas sur les frameworks open source evidemment), acces Git permanent pendant le developpement, clause de transfert de code en cas de resiliation du contrat, documentation technique suffisante pour permettre une reprise par un tiers.

Chez Nehos, le client est proprietaire du code des le premier commit. On lui donne l'acces 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 apres 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 a jour de securite, des corrections de bugs, des evolutions fonctionnelles et un monitoring continu.

Une bonne reponse : l'agence propose un contrat de TMA (Tierce Maintenance Applicative) avec un volume d'heures mensuelles, des SLA de temps de reponse, un rapport mensuel d'activite et une equipe dediee (au minimum 2 developpeurs qui connaissent la codebase).

Une mauvaise reponse : "On verra ca apres la livraison" ou "On facture au temps passe sans engagement." L'absence de TMA structuree signifie que vous dependrez de la bonne volonte de l'agence — qui sera probablement occupee sur de nouveaux projets.

Le cout 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 metier, entre 3 000 et 10 000 euros par mois pour une plateforme complexe. Ce budget couvre les mises a jour de securite, les corrections de bugs, le monitoring et un volume d'evolutions 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 perimetre defini, puis s'etend 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 reponse : l'agence explique sa capacite d'absorption. Par exemple : "Notre equipe de 50 developpeurs nous permet de passer de 2 a 6 developpeurs 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 reponse : l'agence est une equipe de 3 a 5 personnes qui sera saturee si votre projet grossit. Ce n'est pas un defaut en soi (les petites agences font d'excellent travail), mais il faut etre lucide : si le projet double de perimetre, cette agence ne pourra pas suivre et vous devrez en chercher une deuxieme en parallele.

Chez Nehos, notre equipe de 50 experts nous permet de scaler rapidement. On a des profils specialises 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, regie ou hybride ?

Le modele de tarification impacte directement la relation client-agence. Aucun modele n'est universellement meilleur — chacun a ses avantages selon le contexte.

Le forfait (prix fixe pour un perimetre defini) convient quand le cahier des charges est stable et detaille. L'avantage : previsibilite budgetaire. Le risque : l'agence rogne sur la qualite si le forfait est trop serre, ou le client paie des avenants pour chaque changement de perimetre.

La regie (facturation au temps passe) convient quand le projet evolue en cours de route et que le perimetre n'est pas fige. L'avantage : flexibilite totale. Le risque : le budget peut deraper si le suivi n'est pas rigoureux.

L'hybride (forfait pour le cadrage et les livrables principaux, regie pour les evolutions) est souvent le modele le plus equilibre. Le client a une enveloppe budgetaire previsible pour le coeur du projet et de la flexibilite pour les ajustements.

Une bonne reponse : l'agence explique ses 2 a 3 modeles de tarification, recommande celui qui convient a votre contexte et detaille les conditions (TJM en regie, perimetre en forfait, conditions de l'hybride).

Une mauvaise reponse : l'agence ne propose qu'un seul modele ou ne peut pas detailler ses conditions de facturation. Mefiez-vous aussi des devis forfaitaires tres bas qui seront rattrapes par des avenants.

Chez Nehos, on propose les 3 modeles. Pour les projets de plus de 30 000 euros, on recommande generalement l'hybride : forfait pour le cadrage, les wireframes et l'architecture (phase 1), puis regie pour les sprints de developpement (phase 2) avec un budget enveloppe et un suivi hebdomadaire.

Consultez nos tarifs pour voir nos grilles TJM et nos modeles de facturation en detail.

#Les red flags qui doivent vous faire fuir

L'agence ne peut pas nommer les developpeurs qui travailleront sur votre projet. Vous ne savez pas qui ecrit le code de votre application — c'est inacceptable.

L'agence ne donne pas d'acces Git pendant le developpement. Le code est votre propriete. 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 repondre a 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 developpement ?" La sous-traitance n'est pas un probleme en soi si elle est transparente et encadree — mais la sous-traitance cachee est un red flag majeur.

Pas de demo reguliere. Si l'agence ne propose pas de demo fonctionnelle en fin de sprint (toutes les 2 semaines), vous n'aurez de visibilite sur le projet qu'a la livraison finale — et il sera trop tard pour corriger les ecarts.

#La checklist finale avant de signer

Avant de signer le contrat avec l'agence retenue, verifiez ces 12 points.

1. Le contrat inclut la cession complete de propriete intellectuelle sur le code.
2. L'acces Git est garanti pendant le developpement et apres la livraison.
3. Les developpeurs nommes sont identifies et leurs profils LinkedIn sont coherents avec l'expertise annoncee.
4. Les SLA sont contractuels et mesurables (temps de reponse, delais de resolution).
5. Un contrat de TMA est propose avec des modalites claires (volume d'heures, tarif, SLA).
6. Le process de gestion de projet est documente et prevoit des demos regulieres.
7. Les conditions de resiliation sont raisonnables (preavis, transfert de code, documentation).
8. Les references clients sont verifiees (vous avez appele au minimum 2 clients precedents).
9. Le modele de tarification est adapte a votre contexte (forfait, regie ou hybride).
10. La stack technique est justifiee par des arguments lies a votre projet, pas a l'agence.
11. L'agence a une assurance RC Pro et un capital social suffisant.
12. Le perimetre 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, reconsiderez votre choix.