L'argent déjà dépensé sur un logiciel raté est perdu, quelle que soit votre prochaine décision. Il ne peut donc pas être une raison de continuer à payer. Penser le contraire, c'est le piège des coûts irrécupérables.
La seule question qui reste : que va acheter le prochain paiement ? Donnez deux semaines au code existant. Si un vrai client peut faire l'action principale, réparez. Sinon, refaites une petite version.
Ce guide explique pourquoi les porteurs de projet continuent de payer pour du code mort, et vous donne le test des deux semaines. Il montre aussi à quoi ressemble une petite reconstruction, et ce qu'il faut sécuriser avant de décider.
À quoi ressemble le piège des coûts irrécupérables dans le logiciel ?
Imaginez un cas fréquent. Un porteur de projet a payé une agence pendant plus d'un an. L'appli plante à la connexion, le paiement ne marche pas, et aucun vrai client ne l'a jamais utilisée.
Sa demande : « On a déjà payé tellement, il faut juste quelqu'un pour la finir. »
Il n'a pas besoin de quelqu'un pour la finir. Il a besoin qu'on lui dise que l'argent est perdu, qu'il continue ou non, et que la seule question est ce que va acheter le prochain paiement.
C'est comme rester au cinéma devant un mauvais film parce qu'on a payé le billet. Le billet est dépensé dans les deux cas. Le seul choix, c'est de dépenser aussi les deux heures suivantes ou non.
Qu'est-ce que le biais des coûts irrécupérables ?
Le biais des coûts irrécupérables, c'est continuer à investir dans quelque chose à cause de ce qu'on y a déjà mis. La bonne question, c'est ce que cela rapportera désormais.
C'est l'un des biais les mieux documentés en économie comportementale. En 1985, Hal Arkes et Catherine Blumer l'ont montré avec des billets de théâtre. Ceux qui avaient payé plein tarif un abonnement assistaient à plus de pièces que ceux qui avaient eu une réduction au hasard, alors que tous avaient déjà payé (Arkes et Blumer, 1985).
En dessous se trouve l'aversion à la perte : une perte fait environ deux fois plus mal qu'un gain égal ne fait plaisir (Tversky et Kahneman, 1992). Abandonner un projet raté ne ressemble pas à une écriture comptable. Ça ressemble à une perte personnelle, la preuve qu'on a choisi la mauvaise agence.
Alors le porteur de projet protège sa fierté au lieu de sa trésorerie. Il appelle le prochain paiement « finir », parce que ça sonne comme une récupération. En réalité, c'est le même pari, rejoué avec moins d'argent en banque.
Le code le plus cher d'une startup, c'est celui écrit pour justifier une erreur passée.
Quels sont les signes d'un projet logiciel mort ?
- Des paiements mensuels sans fonction livrée. L'argent est lié au temps, pas à quelque chose qui marche devant de vrais utilisateurs.
- Un beau design et un backend vide. Les maquettes ont l'air finies, alors on croit le produit presque prêt. La base de données a trois tables et aucune règle de sécurité.
- Une réécriture a déjà eu lieu. L'agence a changé de technologie à mi-parcours, donc la moitié du budget a payé du code qui n'existe plus.
- Personne côté client ne sait lire le code. Chaque point d'avancement est une promesse, jamais un lien.
Rien de tout cela ne veut dire que le porteur de projet est naïf. Il achetait de l'effort alors qu'il aurait dû acheter des preuves.
Faut-il réparer ou refaire ?
Les réécritures ont mauvaise réputation, en partie méritée. Le célèbre texte de Joel Spolsky sur Netscape prévient que jeter du code qui marche, c'est jeter des années de bugs corrigés et de leçons (Spolsky, 2000). Si votre logiciel marche, a des utilisateurs et est juste devenu désordonné, réparez-le morceau par morceau.
Mais cet avertissement suppose que le code marche. Un projet sans utilisateurs n'a rien appris. Il n'y a rien à conserver, sauf la facture.
Utilisez donc une règle simple. Donnez deux semaines à un ingénieur expérimenté avec le code, et une seule question à trancher.
Un vrai client peut-il faire l'action principale, de bout en bout, en production, à la fin de ces deux semaines ?
| Ce que vous voyez après deux semaines | Ce que ça veut dire | Décision |
|---|---|---|
| Le parcours principal marche, le code est désordonné | Le capital est réel, la qualité non | Réparer sur place |
| Le parcours principal marche presque, une partie est cassée | La structure tient, une partie non | Remplacer seulement cette partie |
| Rien ne marche de bout en bout, le modèle de données est faux | Il n'y a pas de capital, juste des dépenses | Refaire en petit |
| Personne ne sait même le mettre en ligne | L'agence était le seul moyen de le faire tourner | Refaire en petit, et posséder son hébergement |
Les deux semaines coûtent quelque chose. C'est l'information la moins chère que vous achèterez de l'année.
À quoi ressemble une reconstruction rapide et petite ?
La reconstruction doit être assez petite pour ne pas devenir le prochain coût irrécupérable. Ma règle : trois écrans, une base de données, un seul moyen de paiement.
| Élément | Ce que ça veut dire |
|---|---|
| Trois écrans | Ce que c'est, ce que vous vendez, et l'action. S'il en faut plus pour prouver qu'on paiera, le périmètre cache une décision |
| Une base de données | Un Postgres géré comme Supabase, avec des règles d'accès dès le premier jour pour que les droits vivent dans la base |
| Un seul moyen de paiement | En Algérie, le paiement à la livraison d'abord. La carte via un prestataire comme Chargily vient plus tard, quand les commandes prouvent la demande |
J'explique toute la logique de coût dans la formule à 50 000 DA, et pourquoi léger ne veut pas dire bâclé dans minimum viable, pas minimum d'effort.
Une reconstruction comme ça sort en semaines, pas en saisons. Et elle sort quelque chose qu'un client peut utiliser, la seule chose qui vous dit s'il vaut la peine de dépenser plus.
Pourquoi ce piège est-il plus dur en Algérie ?
L'argent est souvent celui de la famille. L'abandonner, ce n'est pas qu'une perte financière, c'est une discussion au dîner. Le coût d'orgueil dépasse alors le montant.
Se faire rembourser est difficile. Un litige sur une appli inachevée finit rarement par un remboursement, donc « finir » semble la seule façon de récupérer quelque chose.
Le code n'appartient souvent pas au porteur de projet. Beaucoup n'ont jamais reçu le dépôt de code, les mots de passe du serveur ou les comptes des stores. Avant toute décision, le premier travail est la propriété : code source, domaine, hébergement, base de données, comptes Play Store et App Store, tous à votre nom.
Quelles erreurs fait-on face à un projet logiciel raté ?
- Payer la prochaine facture pour « finir » sans test. Faites d'abord le test des deux semaines.
- Mélanger deux questions. « Était-ce une erreur ? » parle du passé. « Que va acheter le prochain paiement ? » parle du futur. Seule la seconde a le droit de vote.
- Accepter des comptes rendus au lieu de liens. Chaque paiement doit être lié à quelque chose que vous ouvrez sur votre téléphone.
- Refaire le même grand plan. Une reconstruction à quatorze écrans, c'est le prochain coût irrécupérable.
- Décider avant de posséder le code et les comptes. On ne répare pas ce qu'on ne contrôle pas.
Que faire cette semaine ?
- Aujourd'hui : listez tout ce que vous ne possédez pas encore : code, hébergement, domaine, base de données, comptes des stores. Demandez-les par écrit.
- Cette semaine : demandez à un ingénieur indépendant de faire le test des deux semaines.
- À partir de maintenant : liez chaque paiement à une fonction qui marche et que vous pouvez ouvrir vous-même.
- Si la réponse est de refaire : réduisez à trois écrans et refusez toute fonction qui n'aide pas un inconnu à vous payer.
- Ensuite : laissez les vraies commandes décider de la suite.
Pourquoi les projets coûteux finissent-ils ici ? Je l'explique dans pourquoi les applis chères meurent avant leur lancement.