Il existe des dizaines d'articles en ligne listant les « questions à poser à votre agence logicielle ». La plupart sont écrits par des agences, et la plupart sont intéressés — conçus pour que l'agence ait l'air bien quand vous posez leurs questions suggérées.
Celui-ci est différent. On écrit du côté agence, et on vous dit les questions qui comptent vraiment — y compris celles que la plupart des prospects oublient de poser et celles que les agences espèrent que vous ne poserez pas.
Si vous évaluez des agences en ce moment, imprimez cette liste. Les réponses vous en diront plus que n'importe quel deck commercial.
Questions sur leur façon de travailler
« À quoi ressemble votre processus de livraison, étape par étape ? »
C'est la question la plus importante de cette liste. Si l'agence ne peut pas vous expliquer son processus — du kickoff au déploiement — en termes clairs et concrets, c'est qu'elle n'en a pas. Elle improvise.
Une bonne réponse inclut des phases spécifiques (cadrage, design, développement, tests, déploiement), des livrables spécifiques à chaque phase, et une explication claire de quand et comment vous verrez les progrès. On a publié l'intégralité de notre processus de livraison — c'est le niveau de détail que vous devriez attendre.
« À quelle fréquence verrai-je du logiciel fonctionnel ? »
La réponse devrait être « toutes les deux semaines » ou une fréquence équivalente. Si la réponse est « à la fin » ou « quand ce sera prêt », c'est un signal d'alarme. Vous ne devriez jamais passer plus de deux semaines sans voir une démo fonctionnelle de ce qui est construit.
Les agences qui résistent aux démos fréquentes cachent généralement quelque chose — soit un progrès lent, soit une qualité médiocre, soit un écart entre ce que vous avez demandé et ce qu'elles construisent.
« Comment gérez-vous les changements de périmètre ? »
Les changements de périmètre arrivent sur chaque projet. La question n'est pas s'ils arriveront — mais comment l'agence les gère. Une bonne réponse explique le processus de compromis : le nouveau travail est évalué, le client voit l'impact sur le calendrier et le budget, et la décision est prise ensemble.
Une mauvaise réponse : « on verra au fil de l'eau. » Une encore pire : « notre forfait couvre tout. » Cette deuxième réponse signifie qu'ils bâcleront ou vous factureront des avenants plus tard. On a écrit sur comment les modèles de tarification affectent cette dynamique en détail.
Questions sur ce que vous posséderez
« Qui est propriétaire du code à la fin du projet ? »
Vous devriez l'être. Point. Le code devrait vivre dans un dépôt Git qui vous appartient, avec un accès complet dès le premier jour. Si l'agence hésite sur cette question, ou parle de vous « licencier » le code, partez.
Certaines agences utilisent la propriété du code comme levier — elles construisent votre logiciel sur leur infrastructure, dans leur dépôt, et vous ne pouvez jamais partir sans tout perdre. Ce n'est pas un partenariat. C'est un piège.
« Quelle documentation recevrai-je ? »
Au minimum : vue d'ensemble de l'architecture, instructions d'installation, configuration de l'environnement, et un guide pour le prochain développeur qui travaillera sur le code. Si l'agence dit « le code se documente lui-même », ça veut dire qu'ils n'écrivent pas de documentation.
La documentation est ce qui rend votre logiciel maintenable après la fin de l'engagement. Sans elle, vous êtes verrouillé avec l'agence que vous le vouliez ou non. On en parle dans notre article sur ce qui se passe après le lancement.
« Puis-je internaliser ou changer d'agence plus tard ? »
La réponse devrait être un « oui » enthousiaste. Une bonne agence construit du logiciel maintenable par n'importe qui de compétent — pas seulement par elle. Ça implique du code propre, des frameworks standards, de la documentation, et la propriété complète du code.
Si l'agence semble mal à l'aise avec cette question, demandez-vous pourquoi.
Questions sur leurs choix techniques
« Quelle est votre stack technique, et pourquoi ? »
La technologie spécifique compte moins que la capacité de l'agence à expliquer son choix. « On utilise Laravel pour l'écosystème, le vivier de talents, et l'approche convention-over-configuration » est une bonne réponse. « On utilise ce que le client veut » ne l'est pas — ça veut dire qu'ils n'ont pas d'opinion réfléchie.
Une agence qui change de stack à chaque projet est une agence où aucun projet ne partage les mêmes patterns, le même pipeline de déploiement, ou la même approche de maintenance. Cette incohérence vous coûte. On a expliqué notre propre choix de stack en détail.
« Comment gérez-vous le déploiement et l'hébergement ? »
Vous voulez entendre parler de déploiements automatisés, d'environnements de staging, et de mises en production sans interruption — pas « on envoie les fichiers en FTP sur le serveur ». Le pipeline de déploiement compte parce qu'il détermine la vitesse de correction des bugs, la sécurité des mises à jour, et si vos utilisateurs voient un jour une page de maintenance.
« Que se passe-t-il si quelque chose casse en production ? »
Une bonne réponse inclut du monitoring (comment ils détectent les problèmes), des engagements de temps de réponse (à quelle vitesse ils agissent), et un processus d'escalade (que se passe-t-il si c'est critique). Une mauvaise réponse : « ça ne devrait pas arriver. » Ça arrive toujours.
Questions sur l'équipe
« Qui travaillera réellement sur mon projet ? »
Vous voulez des noms et des rôles, pas « notre équipe ». Ce seront les mêmes personnes du début à la fin, ou les développeurs tourneront ? Le chef de projet écrit-il aussi du code ? Aurez-vous un interlocuteur unique ?
Le pire scénario : vous signez grâce aux seniors que vous avez rencontrés en avant-vente, et votre projet est confié à des juniors que vous n'avez jamais vus.
« Utilisez-vous des sous-traitants ? »
Certaines agences le font, et ce n'est pas nécessairement mauvais — mais vous devez le savoir. Les sous-traitants peuvent introduire des problèmes de transfert de connaissances et ne sont pas toujours disponibles pour la maintenance plus tard. Si l'agence sous-traite, demandez comment elle gère la qualité et la continuité.
Questions sur l'argent
« Puis-je voir un détail de l'estimation ? »
Un chiffre unique — « 80 000 € » — ne vous dit rien. Vous devez voir la décomposition : combien d'heures pour le design, le développement, les tests, la gestion de projet. Quelles fonctionnalités sont les plus coûteuses ? Où pourriez-vous réduire le périmètre pour baisser le coût ?
Une agence qui ne peut pas détailler son estimation devine. Et si elle devine l'estimation, imaginez comment elle gérera le budget.
« Qu'est-ce qui n'est PAS inclus ? »
Cette question attrape plus d'attentes mal alignées que toute autre. L'hébergement ? Pas inclus. La maintenance continue ? Pas incluse. La migration de contenu ? Les révisions de design au-delà de deux tours ? Les frais de services tiers ? Demandez explicitement ce qui est hors devis.
« Quel est le coût total de possession sur 3 ans ? »
Le coût de développement n'est que le début. Ajoutez l'hébergement, la maintenance, les mises à jour de sécurité, et les évolutions. Un projet à 100K € avec 20K €/an de maintenance est un investissement de 160K € sur 3 ans. Si vous comparez ça à un abonnement SaaS, assurez-vous de comparer les coûts totaux — pas seulement le prix de construction. Notre cadre build-vs-buy couvre ça en détail.
Signaux d'alarme à surveiller
Au fil des années, on a vu des patterns qui prédisent de manière fiable l'échec d'un projet. Surveillez ceux-ci :
Ils ne peuvent pas montrer de travaux précédents. Les NDA sont réels, mais toute agence établie peut montrer quelque chose — des études de cas anonymisées, des captures d'écran avec l'accord du client, ou au minimum une description crédible de projets passés.
Ils sont d'accord avec tout. Une agence qui ne repousse jamais, ne dit jamais « c'est une mauvaise idée », et ne suggère jamais d'alternatives est une agence qui vous dira ce que vous voulez entendre jusqu'à ce qu'il soit trop tard.
Ils ne s'engagent pas sur un processus. « On est flexibles » et « on s'adapte à chaque client » peuvent signifier « on n'a pas de processus ». La flexibilité, c'est bien. L'absence de structure, non.
Ils bâclent la phase de cadrage. Si l'agence veut sauter directement au développement sans cadrage correct, soit elle est désespérée pour du revenu, soit elle ne comprend pas assez bien le projet. Dans les deux cas, vous paierez plus tard.
Ils ne peuvent pas expliquer leur tarification. Si l'estimation est un chiffre rond sans détail, ou s'ils deviennent défensifs quand vous demandez comment ils l'ont calculée, c'est un problème.
Utilisez cette liste
Avant votre prochain rendez-vous avec une agence, parcourez ces questions. Notez les réponses. Comparez-les entre agences. Celle qui donne les réponses les plus claires et les plus honnêtes — y compris celles que vous ne voulez pas entendre — est probablement le bon choix.
On a rassemblé un ensemble complet de ressources pour quiconque évalue un projet logiciel sur mesure : comment écrire un brief, combien de temps prennent les projets, comment fonctionnent les modèles de tarification, et ce qui se passe après le lancement. Ensemble, ils vous aideront à aborder la conversation avec l'agence préparé.
Envie de nous faire passer cette liste ? On attend vos questions →