Vous avez fait le bon appel de qualification, le client est sérieux, le budget est réaliste. Il ne reste plus qu'à écrire le contrat. Et c'est là qu'une question toute simple fait souvent hésiter les développeurs indépendants : à quel moment demande-t-on l'argent ?
Facturer tout à la fin semble naturel, on livre, on est payé, logique. Sur le terrain, c'est pourtant la manière la plus sûre de se retrouver à travailler des semaines sans aucune garantie, puis à négocier son propre salaire au moment de la livraison, en position de faiblesse. La solution n'est pas nouvelle, elle vient du bâtiment et de l'artisanat : on découpe le paiement en jalons, chacun accroché à une étape concrète du projet.
Pourquoi ne jamais facturer 100% à la fin
Un projet client dure plusieurs semaines, parfois plusieurs mois. Pendant ce temps, vous avancez, vous prenez des décisions, vous immobilisez des heures qui pourraient servir à un autre client. Si tout l'argent tombe à la livraison, trois risques s'accumulent en silence.
Le premier, c'est l'impayé pur et simple : le client disparaît, change d'avis sur le projet, ou traverse une difficulté financière, et vous n'avez rien à faire valoir sur les semaines déjà travaillées. Le deuxième, c'est le rapport de force inversé : au moment de la livraison, c'est vous qui avez besoin d'être payé, pas le client qui a besoin du produit. Il le sait, et certains en profitent pour négocier une remise de dernière minute. Le troisième, plus sournois, c'est la dérive de trésorerie : vous financez le projet de votre client avec votre propre argent, pendant que lui garde le sien jusqu'au bout.
Un paiement en jalons résout les trois à la fois. Il transforme un unique pari final en une série de petits engagements, vérifiables à chaque étape, des deux côtés.
Les répartitions qui reviennent le plus souvent
Il n'existe pas une seule bonne formule, mais deux structures couvrent la grande majorité des projets clients en freelance.
La première, plus simple, convient aux projets courts, de quelques semaines : un acompte de 60% à la signature, un solde de 40% à la livraison. L'acompte couvre le démarrage, l'immersion, les premières décisions techniques. Le solde arrive une fois le produit livré et validé.
La seconde structure convient mieux aux projets plus longs, avec plusieurs étapes visibles : un premier tiers à la signature, un deuxième tiers à la validation d'une étape intermédiaire (par exemple les maquettes validées ou une première version fonctionnelle), un dernier tiers à la livraison finale. Cette répartition en 40/30/30 a un avantage supplémentaire : elle donne au client un point de contrôle avant la fin, ce qui rassure autant que ça vous protège. Si le projet dévie, on le voit au deuxième tiers, pas seulement à la fin.
Dans les deux cas, si le projet inclut un hébergement ou une maintenance après livraison, celle-ci se facture à part, en abonnement, jamais fondue dans les jalons du projet initial. Mélanger les deux brouille la fin du projet : on ne sait plus si on est encore en train de construire ou déjà en train d'entretenir.
À quoi accrocher chaque jalon, concrètement
Le piège classique du paiement en jalons, c'est de les accrocher à des dates plutôt qu'à des livrables. « Le 15 du mois » n'est pas un jalon, c'est un espoir. Si le projet prend du retard, la date passe et personne ne sait s'il faut payer quand même.
Accrochez chaque jalon à quelque chose que le client peut voir et valider : les maquettes présentées et approuvées, une version testable en ligne avec les fonctionnalités principales, la livraison finale avec transfert des accès. Tant que le livrable n'est pas là, le jalon n'est pas atteint, et inversement, dès qu'il est là, il n'y a plus de raison de retarder le paiement associé. Cette logique protège tout le monde : le client ne paie jamais pour du vent, et vous n'attendez jamais un paiement suspendu à une date arbitraire.
C'est aussi pour cette raison que le cahier des charges rédigé en amont a une valeur qui dépasse la simple description technique : c'est lui qui définit, noir sur blanc, ce que « la version intermédiaire » et « la livraison finale » veulent dire concrètement. Sans cette définition écrite, chaque jalon devient une négociation.
Ce qu'on met noir sur blanc dans le contrat
Un contrat de projet client bien écrit ne se contente pas d'indiquer un prix total. Il précise, pour chaque jalon : son montant exact, le livrable qui le déclenche, et le délai de paiement une fois ce livrable remis (dix jours, quatorze jours, à vous de choisir mais fixez-le). Il précise aussi ce qui se passe en cas de retard de paiement : suspension du travail, pénalité, ou simplement rappel avec nouveau délai. Là encore, l'objectif n'est pas de se montrer méfiant envers le client, c'est d'écrire une fois pour toutes des règles que personne n'aura à réinventer sous tension le jour où un paiement traîne.
Le contrat gagne également à préciser le nombre de retours inclus à chaque étape (par exemple deux séries de modifications sur les maquettes), pour éviter qu'une étape validée soit rouverte indéfiniment sans jamais débloquer le jalon suivant. Un projet sans limite de retours n'a, par définition, pas de fin.
Que faire quand un jalon traîne à être payé
Même avec un contrat clair, un jalon en retard arrive de temps en temps. La règle la plus simple, et la plus efficace, c'est de ne jamais entamer l'étape suivante tant que le jalon précédent n'est pas réglé. Ce n'est pas un caprice, c'est de la cohérence : le paiement du jalon est justement la preuve que le client s'engage sur la suite.
Dans les faits, cela reste rare avec un client sérieux, celui que votre appel de qualification a précisément permis d'identifier. La plupart des retards viennent d'un oubli administratif, pas d'une mauvaise foi, et se règlent avec une simple relance. Mais garder cette règle en tête vous évite d'accumuler, projet après projet, des heures non payées en espérant que « ça se régularise à la fin ».
Une structure qui protège les deux parties
Découper un projet en jalons n'est pas une manière de se méfier de son client, c'est une manière de rendre le projet lisible pour vous deux. Le client sait exactement à quel moment il paie et pourquoi. Vous savez exactement quand votre trésorerie avance, sans dépendre d'un unique paiement final incertain. Et le projet lui-même y gagne : chaque jalon devient un point de vérification naturel, bien avant la livraison finale.
Cette logique de jalons, de cahier des charges et de contrat s'apprend bien plus vite avec des modèles concrets qu'en les réinventant seul à chaque nouveau client. C'est exactement ce que couvre la formation Concevoir un projet full-stack de A à Z, de l'appel de qualification jusqu'à la maintenance après livraison.