Ca arrive dans toutes les agences. Le projet est livré, le client dit 'c'est bien', deux semaines passent, et là il revient avec une liste de 23 points 'qu'il n'avait pas vus avant'. Pas de validation écrite. Pas de bon à tirer signé. Juste un 'ok' à l'oral en fin de call. Résultat : trois semaines de retouches non facturées, un chef de projet à bout de nerfs, et une facture finale contestée.
Ce scénario, j'en ai parlé avec la directrice de production d'une agence web lyonnaise de 14 personnes. En 2024, elle a calculé que 31% du temps non facturable de son équipe partait dans des retouches post-livraison non cadrées. Trente et un pourcent. C'est presque un ETP entier parti en fumée chaque année sur ce seul point.
Pourquoi la recette client est le maillon le plus sous-estimé d'un projet
La plupart des agences bossent dur sur leur brief, leur rétro-planning, leur stack technique. Mais la recette, la phase de validation formelle des livrables, elle est traitée comme une formalité. On envoie un lien, on attend un retour, et on espère. C'est une erreur stratégique.
La validation d'un livrable n'est pas qu'une question de qualité. C'est un acte juridique. Un jalon contractuel. Sans validation formalisée, vous ne pouvez pas déclencher une facture en toute légitimité, vous ne pouvez pas clore un sprint, et vous ne pouvez pas opposer quoi que ce soit au client qui reviendrait deux mois plus tard pour exiger des modifications 'incluses'.
On a perdu un contrat de 18 000 euros de solde parce qu'on n'avait aucune preuve écrite que le client avait validé la version finale du site. Il a dit que ce n'était 'pas ce qu'il avait demandé'. On n'avait rien. Depuis, chaque livrable passe par un bon de recette signé, point final. -- Sebastien R., directeur associé, agence e-commerce, Bordeaux
Les 4 types de livrables et leur processus de validation associé
Tous les livrables ne se valident pas de la même façon. Une maquette graphique, une campagne Meta Ads, un module de développement custom et un rapport de performance mensuel n'appellent pas du tout le même protocole. Erreur classique : appliquer le même process à tout.
- Livrables visuels (maquettes, chartes, vidéos) : validation en deux tours maximum, avec grille de relecture fournie au client en amont. Si la grille n'est pas remplie, le retour n'est pas recevable.
- Livrables techniques (développements, intégrations, APIs) : recette formelle avec cahier de tests, validée environnement par environnement. Chaque test signé ou horodaté.
- Livrables stratégiques (audits, recommandations, benchmarks) : présentation orale obligatoire + compte-rendu de réunion avec validation explicite dans les 5 jours ouvrés.
- Livrables récurrents (reportings, contenus, newsletters) : validation tacite avec délai court (48h), passé ce délai le livrable est considéré validé si aucune réserve n'est émise.
Ce dernier point, la validation tacite, est souvent négligé alors qu'elle règle 80% des frictions sur les projets récurrents. Il faut qu'elle soit explicitement mentionnée dans le contrat ou les CGV. Sans ça, elle ne vaut rien.
Construire un processus de recette en 5 étapes concrètes
Etape 1 : Définir les critères d'acceptation avant de démarrer
En Agile, on parle de 'Definition of Done'. L'idée vaut pour n'importe quelle agence, même non-tech. Avant de commencer un livrable, le client et l'équipe s'accordent par écrit sur ce qui constitue un livrable terminé et validable. Ca prend 20 minutes. Ca évite 20 heures de retouches.
Etape 2 : Créer un document de recette type par nature de livrable
Un bon de recette n'est pas un email. C'est un document structuré qui liste les éléments livrés, les critères de validation, les réserves éventuelles du client, et sa signature ou validation électronique. Notion, un PDF signé via DocuSign, ou directement via le portail client de Clynt, peu importe l'outil. Ce qui compte, c'est la traçabilité.
Etape 3 : Cadrer les rounds de retouches dans le contrat
Franchement, si ce n'est pas dans le contrat, ça n'existe pas. 'Deux allers-retours inclus' doit figurer noir sur blanc, avec une définition claire de ce qui constitue un aller-retour. Un retour de 15 points de correction = un aller-retour, pas quinze. C'est une nuance que beaucoup de clients testent en live.
Etape 4 : Instaurer un délai de réponse contractuel
Le client a 5 jours ouvrés pour valider ou émettre des réserves. Passé ce délai, le livrable est réputé accepté. Cette clause, correctement rédigée et acceptée lors de la signature du devis, change tout. Elle met fin à la procrastination côté client, qui bloque parfois les projets pendant des semaines sans que personne n'ose relancer.
Etape 5 : Lier la validation au déclenchement de la facturation
C'est là que beaucoup d'agences se tirent une balle dans le pied : elles facturent avant la validation, ou elles valident sans facturer dans la foulée. La validation d'un livrable doit automatiquement déclencher l'émission de la facture associée au jalon. Avec un outil comme Clynt, ce lien entre jalon validé et déclenchement de facture peut être automatisé, ce qui évite les oublis et les décalages de trésorerie.
Les signaux d'alerte que votre process de recette est cassé
Un chef de projet m'a partagé un cas concret chez un client SaaS B2B : leur cycle de validation moyen était de 19 jours par livrable. Dix-neuf jours. Leur TJM moyen était de 650 euros. Chaque livrable en attente de validation gelait en moyenne 2 jours de charge équipe. Sur 12 livrables par trimestre, ca représentait 24 jours de portage gratuit. Le truc absurde, c'est qu'en instaurant un simple délai contractuel de 5 jours avec validation tacite, ils sont passés à 6 jours de cycle moyen en un trimestre.
Autres signaux que le process est à refaire : des clients qui 'redécouvrent' des problèmes après avoir validé, des chefs de projet qui relancent à la main sans aucun suivi systématique, des factures de solde qui s'accumulent en fin de projet parce que personne n'a formalisé les validations intermédiaires.
Ce que les meilleurs portails client changent concrètement
Le portail client n'est pas un gadget. Quand il est bien configuré, il centralise les livrables, les demandes de validation, les commentaires, et garde une trace horodatée de chaque action. Le client voit ce qu'il doit valider, il clique, il valide, c'est enregistré. Plus d'ambiguité sur 'j'ai dit ok à l'oral' versus 'j'ai jamais validé ça'.
Clynt propose ce type d'espace client intégré, directement connecté au suivi de projet et à la facturation. Ce n'est pas anecdotique : l'intégration entre validation et facturation est justement ce qui manque à 90% des agences qui bricotent avec des outils séparés, un Google Drive pour les livrables, HubSpot pour le CRM, Pennylane pour la compta, et un email pour les validations. Le cloisonnement tue la traçabilité.
FAQ
Quelle est la différence entre un bon de recette et une validation par email ?
Un email de validation a une valeur juridique limitée et difficile à prouver en cas de litige. Un bon de recette structuré, signé électroniquement ou validé via un portail horodaté, constitue une preuve solide et opposable. En cas de contentieux, c'est la différence entre gagner et perdre.
Combien de rounds de correction inclure dans un contrat d'agence ?
Deux rounds est le standard marché pour la plupart des livrables créatifs ou stratégiques. Au-delà, chaque round supplémentaire doit être facturé au temps passé ou forfait. L'essentiel est que le contrat le précise explicitement, avec une définition claire de ce qui constitue un 'round'.
La validation tacite est-elle légalement valable en France ?
Oui, sous conditions. Elle doit être explicitement prévue dans le contrat ou les CGV signés par le client, avec un délai clairement mentionné. Le silence du client passé ce délai vaut acceptation. Un avocat spécialisé en droit du numérique peut vous aider à rédiger cette clause pour qu'elle soit inattaquable.
Comment gérer un client qui refuse de valider sans donner de raison précise ?
C'est le cas le plus délicat. La bonne pratique : mettre en demeure par écrit en rappelant le délai contractuel et en demandant des réserves motivées et précises. Si le client ne peut pas lister de points concrets, son refus n'est pas recevable au regard des critères d'acceptation définis en début de projet.