Erreur 1 — Un brief trop vague pour être actionnable
Le brief est le document le plus important d'un projet digital, et le plus souvent bâclé. "Refaire notre site pour qu'il soit plus moderne" n'est pas un brief. "Créer un site qui convertit les visiteurs en demandes de démo, avec une page par offre, un formulaire de contact simplifié, et une intégration HubSpot" est un brief.
Un bon brief répond à cinq questions. Quel est l'objectif business précis ? Qui est l'utilisateur cible et qu'est-ce qu'il cherche ? Quelles sont les contraintes (budget, délai, technologies existantes) ? Quels sont les critères de succès mesurables ? Quels exemples vous plaisent, et lesquels vous déplaisent ? Sans ces réponses, chaque prestataire interprétera librement, et rarement dans le même sens que vous.
Erreur 2 — Pas de référent interne dédié
Un projet digital avec une équipe externe a besoin d'un interlocuteur côté client qui a le temps, l'autorité et la réactivité nécessaires. Si cette personne change en cours de projet, valide avec 3 semaines de retard ou n'a pas le pouvoir de décider, le projet dérive.
Le référent interne n'a pas besoin d'être technique. Il doit comprendre les objectifs business, pouvoir arbitrer les choix de contenu et de priorité, et rester disponible pour des échanges hebdomadaires. Si personne en interne ne peut jouer ce rôle à temps partiel, c'est le signe qu'il faut soit décaler le projet, soit confier le pilotage à l'extérieur. C'est précisément l'une des missions clés d'un Head of Digital à temps partagé. Cette même logique s'applique d'ailleurs en amont, lorsqu'il faut construire une roadmap digitale sans équipe tech en interne.
Erreur 3 — Les validations trop tardives
Le schéma classique : le client laisse l'agence travailler seule pendant six semaines, découvre les maquettes et réalise que la direction a changé d'avis sur la cible, que le tone of voice est faux, et que deux sections entières sont à refaire. Résultat : deux semaines de retard et une tension relationnelle qui ne se résoudra jamais complètement.
La règle tient en une phrase : une validation par livrable, avec des jalons courts. Les wireframes (structure) avant les maquettes (design). Les maquettes desktop avant le développement. Le développement avant les tests de recette. Chaque étape validée devient un acquis sur lequel on ne revient pas, sauf exception justifiée. La contrainte est réelle, mais c'est elle qui fait avancer le projet sans retour en arrière.
Bonne pratique : imposez un délai de validation contractuel (48 à 72h ouvrées par livrable). Passé ce délai sans retour, le livrable est considéré comme validé. Cela force les équipes internes à s'organiser plutôt que de bloquer le projet par inaction.
Erreur 4 — Le périmètre qui dérive sans contrôle
Le scope creep est l'ennemi silencieux de tout projet digital. Il commence par de petites demandes : "au fait, on pourrait ajouter un chatbot ?", "est-ce qu'on peut aussi faire une version anglaise ?", "j'ai pensé à une nouvelle section…". Prise isolément, chaque demande semble raisonnable. Mises bout à bout, elles font exploser les délais et le budget.
La solution n'est pas de refuser toute évolution, mais de la tracer et de l'arbitrer. Toute demande hors périmètre initial est notée dans un "backlog d'évolutions" avec une estimation de charge. Elle sera intégrée dans une v2 ou fera l'objet d'un avenant. Cette discipline protège tout le monde : le prestataire, qui peut budgéter correctement, et le client, qui garde la maîtrise de ses coûts.
Erreur 5 — L'absence de recette formelle avant la mise en ligne
La recette est la phase de validation finale avant la mise en production. Elle consiste à tester systématiquement chaque fonctionnalité du cahier des charges sur les principaux navigateurs et devices, à documenter les anomalies, puis à les classer par criticité. Beaucoup de projets sautent cette étape "pour aller plus vite", avant de mettre en ligne un site avec des formulaires qui ne fonctionnent pas sur mobile ou des liens cassés en production.
Une recette structurée prend un à trois jours selon la taille du projet. Elle doit être menée par l'équipe cliente, et pas uniquement par le prestataire, qui teste son propre travail, avec une grille de test définie à l'avance. C'est la dernière occasion de corriger avant que les vrais utilisateurs ne découvrent les bugs.
"La qualité d'un livrable digital se mesure le jour où l'utilisateur final l'utilise — pas le jour où l'agence le présente en démo."