Comment choisir une agence web : 10 critères non discutables pour un partenariat qui fonctionne

Choisir une agence web fait partie des décisions structurantes d’un projet digital.

Comparer plusieurs prestataires reste complexe. Les propositions sont difficiles à mettre en regard, les promesses nombreuses, les niveaux de détail variables…

Un site web n’est pas un livrable figé. C’est un produit qui évolue : correctifs, mises à jour, nouvelles fonctionnalités, exigences réglementaires, sécurité, performance.

Choisir une agence, ce n’est donc pas uniquement comparer des devis ou des maquettes. C’est évaluer la capacité d’une équipe à construire un socle solide, maintenable et compréhensible dans le temps.

Si vous êtes CTO, CDP ou responsable marketing, l’enjeu dépasse le rendu final. Il concerne la qualité du code, la gouvernance, la performance, la sécurité et la capacité à faire évoluer le projet sans le fragiliser.

Avant d’entrer dans les critères, posons un cadre simple.

Ce que l’on évalue mal dans un appel d’offres

En appel d’offres, la comparaison se concentre naturellement sur des éléments visibles : budget, planning, maquettes, stack technique.

Ces critères sont légitimes, mais ils restent pourtant incomplets.

On parle beaucoup moins de maintenance (TMA), de SLA, de gouvernance de release, de dette technique ou de réversibilité prestataire.

Or, sur la durée, ce sont précisément ces éléments qui structurent la relation et le coût réel du projet.

Le terrain le montre régulièrement : un site peut être livré dans les temps et conforme au cahier des charges, tout en devenant difficile à faire évoluer quelques mois plus tard.

Sur trois ans, le run représente souvent la part majoritaire du coût total.

Il ne s’agit pas d’un supplément au projet initial : c’est son prolongement naturel.

Comparer une agence ne consiste donc pas uniquement à évaluer sa capacité à livrer. Il s’agit d’estimer sa capacité à maintenir, faire évoluer et sécuriser un système dans le temps.

Voici 10 points à explorer, et ce que ça dit vraiment d’un prestataire.

1. Références comparables (et vérifiables)

Une référence non comparable peut donner un faux sentiment de sécurité.

Un site vitrine PME ne prépare pas forcément à un SI complexe.

Un e-commerce simple ne garantit pas la tenue d’un écosystème interconnecté (CRM, SSO, ERP, DAM…).

Le risque le plus fréquent : sous-estimation des charges et des intégrations.

Ce qu’il est pertinent de vérifier

• Projets similaires en volumétrie et complexité.
• Stack comparable.
• Possibilité d’échanger avec un client.
• Cas détaillant contraintes et arbitrages.
• Indicateurs post-livraison (stabilité, performance, évolutions).

Signaux faibles

• Portfolio uniquement orienté design.
• Refus de détailler la complexité technique.
• Références anciennes ou très vagues.

Un cas vécu : une “référence grand compte” qui s’est révélée être un microsite isolé, sans intégration SI. Le projet cible impliquait SSO, CRM et workflow multi-équipe. Quatre mois de dérive plus tard, la comparabilité marketing avait montré ses limites.

2. Compétences internes réelles (notamment techniques)

Pourquoi c’est déterminant

Si les compétences clés sont instables ou très externalisées, la qualité devient imprévisible.

La sous-traitance n’est pas un problème en soi.

Le manque de transparence, si.

Ce qu’il est utile de demander

• Organigramme projet nominatif.
• Lead developer identifié.
• Ancienneté moyenne.
• Taux de sous-traitance.
• Possibilité d’échanger avec l’équipe technique.

Les retards liés à un turn-over important ou à une sous-traitance mal cadrée sont un scénario courant. La stabilité des équipes est souvent un actif sous-estimé.

3. Qualité & maintenabilité

Un site mal structuré devient fragile.

Chaque évolution coûte plus cher que la précédente.

Points à objectiver :

• Standards documentés.
• Revues de code formelles.
• Tests automatisés.
• CI/CD actif.
• Suivi explicite de la dette technique.

Un simple “On teste à la main” mérite d’être creusé.

Preuves concrètes attendues :

• Capture de pipeline CI/CD.
• Rapport d’analyse statique.
• Exemple de pull request commentée.
• Backlog de dette priorisé.

Ce critère conditionne la facilité d’évolution. Il prépare naturellement le suivant : la performance.

4. Performance & accessibilité

Performance et accessibilité ne sont pas des optimisations “de fin de projet”.

Elles influencent SEO, conversion et conformité.

Les Core Web Vitals (LCP, INP, CLS) se mesurent en conditions réelles, pas uniquement en laboratoire.

Il est souvent plus pertinent de vérifier :

• L’existence d’un budget performance formalisé.
• Des mesures en lab et en production.
• Un audit accessibilité (RGAA/WCAG).
• Un monitoring continu.

Un projet où la performance est repoussée en “phase 4” conduit fréquemment à des arbitrages coûteux plus tard.

Traiter tôt ces sujets réduit les corrections lourdes.

5. Sécurité & conformité

Un incident de sécurité dépasse rapidement le coût initial du projet.

Sans être alarmiste, il est sain de vérifier :

• Politique de mises à jour et hardening.
• Scan de vulnérabilités régulier.
• Backups testés (pas seulement activés).
• Plan d’incident documenté.
• Gestion des accès formalisée.

Confondre RGPD et bannière cookie est un raccourci encore fréquent.

6. Transparence des coûts

Un devis incomplet devient souvent une succession d’avenants.

Il est préférable que l’agence explicite :

• Les hypothèses structurantes.
• Les hors-périmètre.
• Les coûts récurrents (run, licences, hébergement).
• Le budget TMA recommandé.

Un partenaire de long terme aide à projeter le coût d’évolution, pas seulement le coût de lancement.

7. Gouvernance & méthode

Sans gouvernance claire, les décisions deviennent diffuses.

Points à clarifier :

• RACI formalisé.
• Rituels projet.
• Gestion des risques.
• Plan de recette.
• Documentation livrée.

Une méthode n’est pas une garantie absolue. Mais l’absence de cadre rend les dérives plus probables.

8. Capacité à gérer le RUN

Un site commence réellement à vivre après la mise en ligne.

Il est rassurant de voir :

• Un contrat SLA clair.
• Un process incident formalisé.
• Un backlog run structuré.
• Un release management maîtrisé.
• Un monitoring actif.

Un incident un vendredi soir sans astreinte prévue rappelle vite que le RUN est une assurance, pas un supplément.

9. Réversibilité & propriété

Pouvoir changer d’agence sans tout reconstruire est un principe de base.

À vérifier :

• Accès complet aux repos.
• Documentation d’architecture.
• Infra-as-code.
• Absence de dépendances propriétaires bloquantes.
• Procédure de transfert formalisée.

La réversibilité n’est pas un manque de confiance.

C’est un mécanisme d’équilibre.

10. Capacité à challenger

Un partenaire ne valide pas tout automatiquement.

Il propose des arbitrages.

Il questionne une demande risquée.

Il aide à prioriser selon la valeur et la soutenabilité technique.

Demander :

“Quand avez-vous déjà dit non à un client ?”

peut être plus révélateur qu’un portfolio.

Le raccourci honnête pour réduire le risque

Choisir une agence web ne revient pas à sélectionner la meilleure présentation ou le devis le plus compétitif. Il s’agit d’évaluer la capacité d’une équipe à construire un système maintenable, sécurisé et évolutif.

Les critères proposés ici ne sont pas des cases à cocher, mais des angles d’analyse pour orienter la discussion vers les sujets structurants : qualité du code, gouvernance, run, sécurité, réversibilité, capacité à arbitrer.

Un partenaire solide accepte d’entrer dans le détail et d’assumer ses choix.

Si certains de ces points restent flous dans votre consultation ou votre projet en cours, un regard extérieur peut aider à objectiver les risques et clarifier les arbitrages avant engagement.

L’objectif n’est pas de remplacer votre équipe, mais de sécuriser la durée.