Jalons, livrables, recette : gérer un projet freelance par étapes

Un jalon est un point d'arrêt dans un projet où un livrable est remis, vérifié et validé. La validation déclenche le paiement et ouvre le jalon suivant. Sans ce découpage, un projet freelance dérive en 2 directions : scope creep ou impayé. Cet article explique comment découper intelligemment, que mettre dans un livrable, et comment mener une recette efficace.

Pourquoi découper — vraiment

Un projet freelance de 30 jours payé à la fin crée 3 problèmes :

1. Risque côté freelance : 30 jours de travail sans garantie de paiement final.
2. Risque côté PME : aucun point de contrôle intermédiaire, découvre le résultat à la fin.
3. Conflits de périmètre : les deux parties n'ont pas un alignement formel en cours de route.

Le découpage en jalons résout les 3 en même temps : chaque jalon est un contrat mini dans le contrat global. Validation partielle = paiement partiel = risque partagé.

Anatomie d'un bon jalon

Un jalon bien défini contient 5 éléments :

1. Un nom : « Setup infrastructure », « Écrans d'authentification », « Intégration paiement Stripe ».
2. Une date cible : « Semaine 3 », ou date calendaire précise.
3. Les livrables attendus : code déployé sur staging, Figma figé, doc technique.
4. Les critères d'acceptation : « L'utilisateur peut créer un compte via email avec double vérification. Tests unitaires > 80 % couvrant l'auth. Déployé sur staging accessible à l'équipe PME. »
5. Le montant associé : pourcentage du prix total (souvent 10-30 % par jalon).

Contre-exemple (mauvais jalon) : « Livrer la v1 en semaine 3 ». Pas de critère, pas de livrable précis, pas de méthode de validation.

Combien de jalons ?

Règle empirique selon la durée du projet :

Trop peu de jalons → risque élevé. Trop de jalons (> 10) → friction administrative qui ralentit le projet.

La recette client — le point de validation qui change tout

La recette (ou UAT — User Acceptance Test) est le processus par lequel la PME valide qu'un livrable correspond aux critères d'acceptation. Sans recette formelle, la validation d'un jalon est une opinion ; avec recette, c'est un contrat respecté.

Le process de recette en 4 étapes

1. Notification de livraison : le freelance pose son livrable disponible, envoie le lien staging ou le fichier.
2. Test côté PME : la PME exécute les cas de test prévus dans les critères d'acceptation. Délai standard : 5-7 jours ouvrés.
3. Statut :
   • Validé : paiement libéré, jalon fermé, prochain jalon ouvert.
   • Refusé : la PME liste précisément les écarts constatés (format : critère X non respecté car Y).
   • Silence : au-delà du délai, validation automatique chez devplace.pro (anti-blocage).
4. Cycle d'ajustement si refus : le freelance corrige, propose une nouvelle livraison. Délai maximum 7 jours. Au 2e refus, escalade médiation.

Ce qui fait une bonne recette côté PME

• Timing prévu dans les ressources : quelqu'un doit être disponible pour tester dans les 5 jours.
• Équipe de test identifiée : souvent 1-2 utilisateurs finaux + 1 référent technique.
• Documentation de test : cas d'usage écrits à tester (idéalement fournis avec le contrat).
• Feedback constructif et précis : « Le bouton X ne fonctionne pas quand je clique alors qu'il devrait faire Y ». Pas « ça marche pas ».

Ce qui fait une bonne recette côté freelance

• Livraison propre : code déployé, lien fonctionnel, pas de bug bloquant évident (QA interne préalable).
• Doc de ce qui a été livré : release notes, liens vers les user stories.
• Disponibilité dans les 48 h après livraison pour répondre aux questions PME.
• Gestion des refus : ne pas prendre personnellement, formaliser la correction, re-livrer proprement.

Livrables typiques par type de projet

Projet dev web/mobile

• Fichiers de code (Git, PR vers main)
• Application déployée (staging/prod)
• Documentation technique (README, schéma architecture)
• Tests automatisés
• Capture des écrans / démo vidéo

Projet design UX/UI

• Maquettes Figma (fichier source, figé en version)
• Design system / tokens
• Prototype interactif
• Documentation des interactions
• Export assets (PNG/SVG)

Projet data / BI

• Notebook ou script reproductible
• Dataset traité / modèle entraîné
• Dashboard ou rapport final
• Documentation de la méthodologie
• Transfert de compétences (1 session de formation)

Projet rédaction / content

• Documents livrés (Google Docs, Notion)
• Versions avec track changes
• Visuels associés
• Plan de publication
• Briefing SEO / meta tags

Avenant : quand et comment

Si la PME veut ajouter un livrable non prévu, ou si le freelance constate une complexité sous-estimée, un avenant formalise le changement :

• Description de l'ajout ou changement
• Impact sur jalons existants
• Montant supplémentaire
• Nouvelle date cible si applicable
• Signé par les 2 parties (signature électronique aussi)

Règle : tout changement > 10 % du budget ou > 1 semaine de délai passe par un avenant, jamais un accord verbal.

FAQ

Un jalon peut-il être très court (1-2 jours) ? Oui. Sur des projets courts (2-3 semaines), un jalon par semaine est normal. En dessous de 1 jour, la friction administrative dépasse le bénéfice.

Qui écrit les critères d'acceptation d'un jalon ? Le freelance les propose (il connaît la faisabilité), la PME les valide ou amende. Chez devplace.pro, le cadrage IA les pré-génère, puis humain ajuste.

Que se passe-t-il si la PME ne teste pas dans les 7 jours ? Validation automatique et libération du paiement. Ceci protège le freelance contre la procrastination PME.

Peut-on renégocier un jalon en cours de projet ? Oui, via avenant signé. Pas d'accord verbal — en cas de litige, seul l'écrit fait foi.

Combien de livrables par jalon ? Entre 1 et 5 en pratique. Un jalon avec 10 livrables devient ingérable en recette. Si un jalon a trop de livrables, le découper en 2.

Pour aller plus loin

• Scénarios de périmètre : MVP, Standard, Extended — structurer un brief en 3 scénarios.
• Paiement sécurisé : Escrow freelance — comment sécuriser un paiement projet.
• Le cadrage en amont : Cadrer un projet freelance avec une IA en 5 minutes.