Comment choisir une agence de développement web pour votre projet ?

Choisir une agence de développement web demande de comprendre ce qu’elle livrera, comment vous pourrez le vérifier et dans quelles conditions vous pourrez faire évoluer le résultat. Un portfolio donne un premier aperçu, mais votre décision mérite aussi une discussion sur les usages, les contraintes techniques et les responsabilités après la mise en ligne.

Ce guide Anaska, propose une méthode de consultation et de sélection. Son objectif : vous aider à constituer un dossier comparable entre prestataires, puis à transformer leurs propositions en engagements vérifiables. Les recommandations d’organisation qui suivent sont des conseils éditoriaux à adapter à votre projet, sans classement d’agences ni estimation tarifaire non documentée.

1. Définir le problème avant de demander une solution

Commencez par décrire ce que vos utilisateurs doivent pouvoir accomplir. « Refaire notre site » laisse beaucoup de place à l’interprétation. « Permettre à un client de retrouver ses documents et de transmettre une demande au bon interlocuteur » donne une base de discussion plus précise. Pour chaque usage, indiquez le public concerné, l’action attendue et la difficulté actuelle.

Dans un exemple fictif, une entreprise souhaite créer un espace professionnel. Le besoin peut couvrir une simple consultation de documents ou inclure des droits différenciés, des validations internes et une connexion à un outil existant. Nous conseillons de décrire ces variantes avant de demander un devis : vous pourrez ainsi repérer ce que chaque agence a réellement compris et chiffré.

Répartissez les fonctionnalités entre celles nécessaires au lancement, celles souhaitables ensuite et celles encore incertaines. Ajoutez vos contraintes : échéance motivée, disponibilité des équipes, contenus à préparer, systèmes à conserver. Si une contrainte reste négociable, précisez-le. L’agence pourra alors proposer un arbitrage explicite entre périmètre, calendrier et organisation, plutôt que construire sa réponse autour d’une hypothèse silencieuse.

2. Préparer un dossier commun à toutes les agences

Adressez aux candidats un même dossier de consultation. Nous recommandons d’y réunir les parcours prioritaires, les contenus disponibles, les intégrations envisagées, les interlocuteurs internes et les questions ouvertes. Vous n’avez pas besoin de décider seul de toute l’architecture. Distinguez simplement ce qui est établi de ce qui doit faire l’objet d’une recommandation.

Pour une refonte, préparez un inventaire de l’existant : pages à conserver, documents à reprendre, comptes utilisateurs, formulaires, données et connexions externes. Demandez aux agences d’expliquer ce qu’elles souhaitent examiner avant de confirmer leur proposition. Une reprise de données peut ainsi être traitée comme un sujet identifié, avec ses vérifications, au lieu d’apparaître tardivement dans les échanges.

Ajoutez une description de votre capacité de contribution. Qui fournira les textes ? Qui validera les maquettes ? Qui répondra aux questions sur les règles métier ? Nous conseillons de communiquer ces responsabilités dès la consultation et de demander un calendrier qui les intègre. Un planning devient plus facile à discuter lorsque chaque validation correspond à un livrable et à une personne désignée.

3. Examiner des références comparables et le rôle réellement joué

Utilisez les réalisations présentées comme des supports d’entretien. Demandez pourquoi un projet ressemble au vôtre : parcours utilisateurs, gestion des droits, intégration à un système tiers, reprise de contenus ou autonomie des équipes. Une proximité visuelle peut vous intéresser pour le design ; pour sélectionner le développement, cherchez aussi des rapprochements dans le fonctionnement attendu.

Faites préciser la contribution exacte de l’agence. A-t-elle conçu les parcours, développé l’application, intégré des maquettes fournies ou assuré la maintenance d’un socle existant ? Demandez quels éléments elle peut présenter pour expliquer son intervention : démonstration autorisée, description des contraintes, exemple de documentation ou retour sur un arbitrage technique. Ne réclamez pas de documents confidentiels.

Si une référence client peut être contactée avec son accord, préparez des questions concrètes : comment les modifications étaient-elles décidées, les anomalies suivies et la reprise organisée ? Traitez les réponses comme un éclairage sur cette collaboration précise. Dans votre propre grille, distinguez toujours ce que vous avez pu examiner, ce qui vous a été déclaré et ce qui reste à confirmer avant signature.

4. Rencontrer l’équipe et comprendre son fonctionnement

Demandez qui interviendra effectivement sur votre projet et dans quel rôle. Identifiez la personne chargée du pilotage, celle qui porte les décisions techniques et les interlocuteurs prévus pour la conception et les vérifications. Si une partie du travail doit être sous-traitée, faites préciser les tâches concernées et la manière dont vous échangerez avec les personnes responsables.

Proposez un entretien autour d’un parcours réel de votre projet. Dans un exemple fictif, un utilisateur modifie une demande déjà validée : l’agence peut vous expliquer les questions qu’elle poserait sur les autorisations, les notifications et l’historique. Observez sa façon de rendre les décisions compréhensibles. Vous devez pouvoir discuter des conséquences sans maîtriser vous-même chaque détail de programmation.

Nous conseillons également de demander un exemple de suivi : compte rendu, tableau des décisions ou présentation d’une livraison intermédiaire, éventuellement anonymisé. Précisez comment une absence sera gérée et qui pourra reprendre les échanges. Votre sélection doit intégrer le temps que votre équipe pourra consacrer au projet : demandez un fonctionnement compatible avec cette disponibilité, ainsi qu’une procédure pour signaler un blocage.

5. Comparer les choix techniques à partir de vos contraintes

Demandez à chaque agence d’expliquer la solution proposée en lien avec vos usages. Pour un système de gestion de contenu, faites démontrer les opérations éditoriales envisagées. Pour une application spécifique, demandez comment seront organisés les comptes, les règles métier et les échanges avec vos autres outils. Évitez de départager les propositions sur une simple liste de technologies.

Nous recommandons de réclamer une courte note de décision : option retenue, alternative examinée, raisons du choix et limites connues. Faites notamment préciser ce qui sera développé pour vous, configuré dans un outil existant ou confié à un service externe. Pour chaque dépendance proposée, demandez les conditions d’utilisation et les dépenses associées, sans présumer qu’elles sont incluses dans le devis.

Lorsque l’incertitude porte sur une connexion essentielle, envisagez une phase exploratoire distincte. Son livrable pourrait être une démonstration limitée, accompagnée des questions résolues et restantes. Définissez à l’avance ce que cette phase doit permettre de décider. L’objectif conseillé est de disposer d’éléments pour poursuivre, ajuster ou arrêter cette piste, sans présenter une expérimentation comme une application prête à être exploitée.

6. Transformer les critères de qualité en preuves attendues

Les expressions « performant », « accessible » ou « sécurisé » méritent une définition dans la proposition. Demandez les pages et parcours concernés, les vérifications prévues, les conditions d’exécution et les documents remis. Le tableau suivant constitue une grille éditoriale de consultation : ses livrables sont des éléments à négocier, pas des prestations supposées incluses chez tous les candidats.

Pour la performance, Web Vitals distingue le chargement, l’interactivité et la stabilité visuelle à travers LCP, INP et CLS. La documentation précise que les mesures de laboratoire ne remplacent pas celles du terrain. Demandez donc comment l’agence vérifiera son travail avant livraison, puis comment les observations réelles seront examinées après lancement. Source : Web Vitals.

Sur l’accessibilité, les WCAG 2.2 présentent des critères testables et décrivent une évaluation combinant automatisation et intervention humaine. Le RGAA détaille notamment des tests sur la présence et la pertinence des alternatives textuelles des images informatives. Demandez un périmètre précis et une méthode de correction, sans assimiler une déclaration commerciale à une évaluation complète. Sources : WCAG 2.2 et critères et tests du RGAA.

Pour la sécurité, l’OWASP présente l’ASVS comme une base de vérification des contrôles techniques et un ensemble d’exigences de développement sécurisé. L’organisation recommande aussi d’inclure la version lorsqu’on référence une exigence. Notre conseil : convenez des exigences pertinentes, du responsable des vérifications et du traitement des écarts. La référence au standard ne constitue pas, à elle seule, une preuve sur votre application. Source : OWASP ASVS.

7. Lire les devis à périmètre et responsabilités comparables

Rapprochez les propositions par livrable avant de comparer leur total. Repérez le cadrage, les parcours, les maquettes, le développement, les intégrations, la reprise de données, les vérifications, la mise en ligne et la formation. Demandez pour chaque poste ce qui sera remis et ce qui permettra de le considérer comme terminé. Une ligne absente appelle une question, pas une supposition.

Faites expliciter les unités de facturation, la devise, le traitement des taxes et les modalités de paiement dans chaque offre. Si une prestation est évaluée au temps passé, demandez comment seront suivies les consommations et approuvés les dépassements. Si le montant est forfaitaire, faites préciser les hypothèses, les exclusions et la procédure applicable lorsqu’un besoin change.

Construisez ensuite une vue des dépenses envisagées après lancement : hébergement proposé, services externes, licences éventuelles, maintenance et évolutions. Nous ne donnons ici aucune fourchette de marché. Appuyez votre comparaison sur les montants et périmètres effectivement écrits par les candidats. Demandez aussi qui souscrira chaque service et qui pourra consulter les factures ou modifier l’abonnement.

Dans un exemple fictif, une offre comprend la reprise des contenus tandis qu’une autre vous laisse cette tâche. Avant de conclure que la seconde est plus avantageuse, évaluez si votre équipe accepte cette responsabilité. Votre décision peut rester la même ; elle reposera alors sur un choix explicite de périmètre et de contribution interne.

8. Préparer la recette avant de signer

La recette désigne ici les vérifications convenues pour examiner la livraison. Nous conseillons de rédiger les scénarios prioritaires avant l’engagement : action de départ, données utilisées, résultat attendu et personne chargée de valider. Incluez les situations ordinaires et les erreurs à traiter, comme un formulaire incomplet ou une opération refusée à un compte non autorisé.

Demandez comment seront consignées les anomalies et distinguées les demandes nouvelles. Faites définir ensemble les catégories de problèmes et leurs conséquences sur la livraison. Par exemple, vous pourriez décider qu’un parcours essentiel inutilisable empêche sa validation, tandis qu’un ajustement visuel identifié suit un calendrier convenu. Il s’agit d’une règle de projet à écrire, sans présumer de ses effets juridiques.

Prévoyez les contenus et accès nécessaires aux vérifications. Pour une administration, faites essayer à un futur contributeur les actions qu’il devra réaliser : créer, prévisualiser, corriger et publier selon le fonctionnement retenu. Demandez également ce qui sera fourni pour reproduire un problème. Une description exploitable doit permettre de retrouver le contexte, les étapes et le résultat observé.

Enfin, discutez du passage en production : personnes présentes, contrôles immédiats, décision de mise en ligne et solution prévue si un problème impose de revenir à l’état précédent. Demandez à voir cette organisation dans la proposition. Vous pourrez alors comparer la préparation du lancement aussi concrètement que les maquettes ou les fonctionnalités.

9. Organiser la maintenance et la possibilité de changer d’agence

Faites distinguer la correction d’une anomalie, l’entretien technique et l’ajout d’une fonctionnalité. Demandez comment chaque demande sera qualifiée, estimée et suivie. Précisez les canaux de contact, les périodes de disponibilité annoncées et la signification des délais proposés : accusé de réception, début d’analyse ou résolution. Appuyez votre choix sur les engagements écrits adaptés à vos besoins.

Nous recommandons de préparer un inventaire des éléments nécessaires à l’exploitation : nom de domaine, hébergement, dépôt de code, comptes de services, documentation et paramètres de déploiement. Pour chacun, faites préciser le titulaire du compte, les accès prévus et la procédure de récupération. Organisez leur transmission par un moyen convenu, en évitant de disperser les informations sensibles dans les échanges courants.

Demandez aussi comment un autre prestataire pourrait reprendre le projet. Les éléments à discuter comprennent la documentation d’installation, les dépendances, les procédures de sauvegarde et de restauration ainsi que les restrictions éventuelles de réutilisation. Faites clarifier les dispositions relatives aux droits et aux livrables dans les documents contractuels, avec un conseil compétent si nécessaire, sans déduire ces droits d’une simple promesse orale.

Pour apprécier la documentation proposée, suggérez une démonstration de reprise sur un environnement convenu. L’agence pourra expliquer les prérequis et les étapes, puis identifier ce qui restera à transmettre. Cette demande constitue un critère de sélection pratique : vous cherchez à comprendre les conditions de continuité avant d’avoir besoin de changer d’interlocuteur.

10. Prendre une décision argumentée et lancer la collaboration

Avant les derniers échanges, fixez vos critères décisifs : compréhension des usages, traitement des inconnues techniques, disponibilité de l’équipe, qualité des livrables et conditions d’exploitation. Séparez les exigences indispensables des préférences. Si une proposition ne répond pas encore à une exigence indispensable, demandez une clarification ciblée avant de la retenir ou de l’écarter.

Organisez une même séance de questions avec chaque finaliste. Faites reprendre les hypothèses, exclusions et responsabilités que vous avez relevées. Demandez une version consolidée de la proposition après les échanges : votre décision doit porter sur un document cohérent, pas sur un assemblage de réponses difficiles à retrouver. Consignez brièvement les raisons du choix et les points à surveiller.

Pour démarrer, reprenez les parcours prioritaires, le calendrier des validations et les livrables attendus avec les personnes qui réaliseront le travail. Faites confirmer les décisions encore ouvertes et leur échéance. Vous pouvez utiliser la sélection d’agences de développement web pour identifier des interlocuteurs, puis appliquer cette méthode à leurs propositions. Si votre besoin reste à formaliser, préparez d’abord les éléments nécessaires pour déposer un projet suffisamment précis.