Acompte et étapes

Pourquoi ne pas tout payer au début, ou à la fin?

Un projet logiciel, ce sont des semaines ou des mois de travail de plusieurs personnes avant que quoi que ce soit soit terminé. Si le client paie tout au départ, il porte seul le risque que le travail soit en retard, mal fait ou jamais livré. S’il paie tout à la fin, c’est le studio qui porte le risque de mois de salaires pour un projet qui pourrait être annulé, transformé au point d’être méconnaissable ou tout simplement impayé.

Ni l’un ni l’autre n’est une bonne base pour travailler ensemble. Un échéancier de paiement sert à garder, à tout moment, l’argent versé et le travail livré proches l’un de l’autre : un désaccord à n’importe quelle étape coûte alors un peu à chacun, pas tout.

Comment fonctionne notre échéancier

Chaque projet à prix fixe que nous acceptons se paie en quatre parties.

1. 01

   Un acompte, avant le début des travaux

   Il réserve l’équipe et paie la découverte et la conception. Il représente une plus grande part d’un petit projet et une plus petite part d’un gros, comme le montre le tableau ci-dessous.

2. 02

   Des paiements par étape

   Le reste, moins la retenue, est réparti entre des étapes adaptées au type de projet : celles d’une application web ne sont pas celles d’un bot ou d’une chaîne de blocs. Chacune se paie quand l’étape est livrée et acceptée.

3. 03

   Une retenue, après la mise en ligne

   Les derniers 10 % sont dus 30 jours après la mise en ligne, une fois la période de garantie terminée sans défaut ouvert. C’est le levier du client pour que tout ce qui est découvert le premier mois soit corrigé.

4. 04

   Les coûts de tiers, au coût

   Le matériel, le temps GPU pour entraîner un modèle, les audits externes et les licences sont facturés d’avance, à ce qu’ils nous coûtent, en dehors des étapes, parce que nous les payons avant le travail qui les utilise.

L’acompte diminue à mesure que le projet grossit pour une raison simple : sur un petit projet, la découverte et la conception représentent une grande part du tout, et l’acompte les paie. Sur un gros projet, un cinquième couvre déjà les premières semaines, et en demander plus ne ferait qu’immobiliser l’argent du client.

Deux échéanciers, calculés maintenant

Les deux exemples ci-dessous sont chiffrés par notre estimateur à partir de la grille tarifaire en vigueur à l’ouverture de la page : les montants sont donc à jour. Les étapes sont celles que le moteur attribue à chaque type de projet.

Ce dont il vous protège

• Payer pour du travail que vous n’avez pas vu. Après l’acompte, l’argent suit les étapes livrées et acceptées.
• Une mise en ligne suivie de silence. La retenue n’est due qu’une fois les 30 premiers jours passés sans défaut ouvert.
• Les surprises sur le prix. Le montant de chaque étape est fixé au départ; un changement que vous demandez fait l’objet d’une demande de modification chiffrée avant tout travail.
• Être captif. Le code, les maquettes et les comptes vous appartiennent une fois payés : à n’importe quelle étape, vous pourriez confier la suite à quelqu’un d’autre.

Ce dont il nous protège

• Commencer un travail qui ne sera jamais payé. L’acompte couvre la première étape.
• Une étape qui n’est jamais approuvée. Une étape est réputée acceptée après un nombre de jours ouvrables sans réponse précisé au contrat.
• Une portée qui grossit sans prix. Les changements passent par une demande de modification, dont une partie est payée avant le début du travail.
• Payer les fournisseurs de notre poche. Le matériel et les autres coûts de tiers sont facturés avant l’achat.

Quand le projet change

Presque chaque projet apprend dans ses premières semaines quelque chose qui change le plan : un écran auquel personne n’avait pensé, une intégration qui s’avère importante, une fonctionnalité qui peut attendre. Un prix fixe ne tient que si les changements ont une porte d’entrée qui ne le déplace pas en douce.

Cette porte d’entrée, c’est la demande de modification. Nous écrivons ce qu’est le changement, ce qu’il ajoute ou retire, et son effet sur le prix et l’échéancier, et vous l’approuvez avant tout travail. Une partie de la demande de modification se paie d’avance et le reste avec l’étape à laquelle elle se rattache : un changement se paie donc comme le travail qui l’entoure. Ce qui sort de la portée sort du prix de la même façon.

L’autre option, absorber les changements sans rien dire jusqu’à la fin, est la façon dont les projets à prix fixe finissent en dispute. Une demande de modification est un petit papier qui évite une grande conversation.

Quand quelque chose tourne mal

Si une étape est en retard de notre côté, vous ne la payez pas avant qu’elle soit livrée. Si vous trouvez un défaut dans un travail accepté, la garantie le couvre, et la retenue assure notre attention plutôt qu’une promesse à relancer. Si un paiement est en retard de votre côté, nous vous le disons, puis nous suspendons le travail après un délai prévu au contrat, plutôt que de continuer en espérant. Les deux parties savent d’avance ce qui arrive, et c’est surtout ce qui rend ces situations rares.

Les questions à poser sur les paiements

1. 01

   Que livre exactement chaque étape?

   Une étape devrait être quelque chose que vous pouvez voir et tester, pas une part du calendrier. « Fonctions principales en préproduction » est une étape; « deuxième mois » n’en est pas une.

2. 02

   Comment une étape est-elle acceptée?

   Qui l’approuve, combien de temps vous avez pour la tester et ce qui se passe si vous trouvez un problème.

3. 03

   Qu’est-ce qui est retenu, et pour combien de temps?

   Une retenue assortie d’une période de garantie vous donne un levier après la mise en ligne. Sans retenue, vous n’en avez aucun.

4. 04

   Comment les changements sont-ils chiffrés?

   Demandez à voir comment une demande de modification est chiffrée avant d’en avoir besoin.

5. 05

   Quand le code vous appartient-il?

   Dès qu’il est payé, pas à la fin de la relation.