Cadrer un projet web au forfait : méthode pour éviter les dérives

Le forfait mal cadré est la première cause de tension entre un freelance et son client. Le client pense avoir demandé X, le développeur a livré Y, les deux ont signé un contrat qui dit Z. Le cadrage en amont n’est pas une formalité administrative — c’est ce qui rend le forfait viable pour tout le monde.

Pourquoi les forfaits dérivent-ils ?

La dérive de périmètre (scope creep) arrive quand les besoins exprimés au départ ne correspondent pas aux besoins réels découverts pendant le projet. Quatre causes récurrentes :

1. Besoins exprimés en solutions, pas en problèmes — “Je veux un chatbot” vs “Je veux réduire les appels au support de 30 %”
2. Décideurs absents au cadrage — les validations arrivent en fin de projet avec de nouvelles exigences
3. Cas limites non explorés — “que se passe-t-il si l’utilisateur annule à l’étape 3 ?” découvert pendant les recettes
4. Dépendances externes sous-estimées — une API tierce qui n’existe pas encore, un accès serveur à obtenir

Phase 1 — Le brief initial (2h)

Avant toute estimation, organiser un brief structuré avec les parties prenantes clés :

Questions obligatoires :

• Quel problème métier ce projet résout-il ? (pas “quoi”, mais “pourquoi”)
• Qui sont les utilisateurs finaux ? Combien ? Dans quel contexte ?
• Quelles sont les contraintes non-négociables ? (deadline, budget, compatibilité)
• Quels systèmes existants doivent s’interfacer ? (CRM, ERP, SI legacy)
• Qui valide les livrables ? Quel est le circuit de décision ?
• Avez-vous des exemples de sites/applications qui vous inspirent ?

Ce qu’on produit à l’issue du brief : Un document d’une page résumant les objectifs, les contraintes et les risques identifiés — que le client valide par écrit avant tout chiffrage.

Phase 2 — Les spécifications fonctionnelles

Les specs fonctionnelles décrivent CE QUE fait le système, pas COMMENT il le fait. Elles constituent la base légale du forfait.

Format minimaliste mais suffisant :

## US-001 — Formulaire de contact

En tant que visiteur du site,
Je veux envoyer un message à l'équipe commerciale
Afin d'obtenir un rappel sous 24h

Critères d'acceptance :
- Le formulaire contient : prénom, email (obligatoire), téléphone, message
- Un email est envoyé à contact@entreprise.com à chaque soumission
- L'utilisateur reçoit un email de confirmation
- En cas d'erreur de validation, les champs incorrects sont signalés en rouge
- Le formulaire est protégé anti-spam (hCaptcha ou honeypot)

Hors périmètre :
- Système de tickets intégré
- Archivage des demandes en base de données
- Statistiques des demandes

La section “Hors périmètre” est aussi importante que les critères d’acceptance. Elle prévient les demandes “ah mais j’avais compris que ça incluait…”

Phase 3 — L’estimation

Estimer un forfait, c’est estimer de l’incertitude. La méthode qui minimise les mauvaises surprises :

Décomposer en tâches élémentaires (max 1 jour chacune)

Tâche	Estimé (j)	Marge (j)	Total
Configuration environnement + CI/CD	0.5	0.5	1
Maquettes (wireframes + validation client)	1	0.5	1.5
Page d’accueil (intégration)	1.5	0.5	2
Formulaire de contact + email	1	0.5	1.5
Tests + recette	1	0.5	1.5
Mise en ligne + documentation	0.5	0.5	1
Total	6	3	9

Règles empiriques :

• Ajouter 30 % pour les imprévus sur un projet bien cadré
• Ajouter 50 % sur une reprise de code existant
• Ajouter 20 % par intégration avec un SI tiers non documenté

Ne jamais afficher la marge dans le devis — le client negotiera dessus et vous vous retrouverez sans filet.

Phase 4 — Le contrat (ce qui protège tout le monde)

Les clauses indispensables d’un contrat de forfait web :

Périmètre précis : référencer les spécifications fonctionnelles signées comme annexe. Ce qui n’est pas dans l’annexe n’est pas dans le forfait.

Procédure de recette : délais (ex : 5 jours ouvrés pour valider chaque livrable), nombre d’aller-retours inclus (ex : 2 cycles de corrections), et ce qui se passe en cas de non-réponse (validation tacite après X jours).

Gestion des modifications : toute demande hors périmètre fait l’objet d’un avenant chiffré avant exécution. Pas de travail gratuit “pour rendre service”.

Conditions de paiement : typiquement 30 % à la signature, 40 % à la livraison de la version bêta, 30 % à la recette finale. Jamais 100 % à la livraison.

Propriété intellectuelle : le code appartient au client à compter du paiement intégral. Les librairies open-source restent sous leur licence d’origine.

Phase 5 — Le suivi pendant le projet

Un forfait bien cadré ne s’oublie pas dans un tiroir. Le suivi actif prévient les dérives.

Réunion de synchronisation hebdomadaire (30 min max) :

• Ce qui a été fait cette semaine
• Ce qui est prévu la semaine prochaine
• Les blocages (attente de contenu, accès, validation)
• Les risques identifiés

Tableau de bord partagé — Notion, Linear, ou même un Google Sheet avec :

• Liste des US en cours/terminées
• Jours consommés vs estimés
• Anomalies ouvertes

Alerte dès 80 % du budget consommé — pas à 100 %. Si vous avez consommé 80 % du budget estimé et qu’il reste 40 % du travail, le problème doit être adressé immédiatement, pas à la livraison.

Ce qui tue un forfait

• Accepter des “petites choses vite fait” en dehors du périmètre — elles s’accumulent
• Commencer à coder avant que les specs soient validées — vous allez tout refaire
• Ne pas impliquer le client en continu — la recette finale sera un choc
• Sous-estimer la recette — comptez 15-20 % du budget total pour les tests et corrections

Conclusion

Un forfait réussi se gagne avant de démarrer, pas pendant. Deux jours de cadrage rigoureux sauvent deux semaines de corrections en fin de projet. La qualité du cadrage est directement proportionnelle à la qualité de la relation client pendant tout le projet.