Développement logiciel

Après la v1 : ce que coûte vraiment de faire évoluer un logiciel sur mesure

Un logiciel sur mesure ne se livre pas, il se met en service. Tout ce qui compte ensuite se joue sur la façon dont vous demandez un changement.

Publié le 25 juillet 2026 — Algeria Agency

La partie visible d’un projet logiciel est sa construction : un devis, des semaines de travail, une mise en service. La partie qui dure est celle d’après, et elle a une monnaie différente. On n’y achète plus un logiciel, on y achète des changements, un par un, pendant des années.

C’est là que les relations se cassent, et presque jamais pour des raisons techniques. Un devis à cinq fois le prix attendu. Une correction facturée que le client croyait couverte. Une modification qui casse autre chose. Une file d’attente invisible où chacun croit que sa demande est la prochaine.

Cet article décrit cette période. Il s’adresse au dirigeant qui utilise déjà un outil fait pour lui et se demande pourquoi le faire évoluer coûte ce que cela coûte. L’article qui l’accompagne traite du choix et de la construction — le cahier des charges, le forfait, la reprise de données — et rien de cela n’est repris ici.

Il ne cite aucun chiffre, et la première section explique pourquoi : la question naturelle, « combien coûte une évolution », n’a pas de réponse comparable d’un devis à l’autre, et la raison est plus intéressante que l’absence.

La v1 n’est pas un livrable, c’est un point de départ

Un logiciel fait sur mesure est le seul achat de votre entreprise dont vous découvrez le besoin réel en l’utilisant. C’est vrai par construction : il a été écrit pour une façon de travailler que personne n’avait décrite complètement, parce que personne ne décrit complètement ce qu’il fait tous les jours.

La conséquence est que la première version est toujours une hypothèse, et que les semaines qui suivent la mise en service produisent plus d’informations utiles que les mois de spécification qui l’ont précédée. Ce n’est pas un échec de conception, c’est le mécanisme normal.

Ce que cela change tient au budget plutôt qu’à la méthode. Un budget qui s’arrête à la livraison finance la partie du travail faite avec le moins d’information, et laisse sans financement la partie faite avec le plus. C’est exactement le mauvais sens.

La règle utile est donc de garder une réserve pour les trois mois qui suivent la mise en service, avant même de savoir à quoi elle servira. Un projet qui consomme la totalité de son budget le jour de la livraison est un projet qui ne pourra pas apprendre de ses propres utilisateurs.

Pourquoi deux devis pour la même demande diffèrent d’un facteur cinq

C’est la question qui amène ici, et elle mérite mieux qu’un soupçon de malhonnêteté. Demandez « ajouter une remise sur les commandes » à trois prestataires et vous obtiendrez trois prix très éloignés. Aucun n’est nécessairement gonflé : les trois ont chiffré des choses différentes.

Le premier a compris une remise en pourcentage saisie à la main sur la commande. Le deuxième y a ajouté les règles que la phrase implique sans les dire : qui a le droit de l’accorder, jusqu’à quel plafond, ce qu’elle devient sur une facture déjà émise, comment elle apparaît en comptabilité. Le troisième a inclus la reprise des commandes existantes et l’état des rapports passés.

Il n’existe donc pas de prix de marché pour une évolution, et ce n’est pas parce que le chiffre serait caché ou mal mesuré. C’est qu’il n’y a pas d’unité commune : les trois devis ne portent pas sur le même objet. Un écart entre eux mesure l’ambiguïté de la demande, pas la cherté d’un fournisseur.

La conséquence est pratique et immédiate. Comparer des devis n’a de sens qu’après avoir écrit ce que la demande contient et ce qu’elle ne contient pas — et c’est le travail de la section suivante. Comparé avant, le moins-disant est simplement celui qui a compris la demande la plus petite.

Décrire un changement : ce qui existe, ce qui change, ce qui ne doit pas bouger

Une demande d’évolution utile tient en trois paragraphes et se rédige sans vocabulaire technique. Le premier décrit ce qui se passe aujourd’hui, avec un cas réel plutôt qu’en général. Le deuxième décrit ce qui devrait se passer à la place, sur le même cas. Le troisième, celui qu’on oublie, dit ce qui ne doit surtout pas changer.

Ce troisième paragraphe est le plus rentable des trois, parce qu’il transforme une conversation à venir en une contrainte écrite. « Les commandes déjà validées gardent leur ancien prix » est une phrase qui coûte dix secondes à écrire et qui, absente, produit une semaine de discussions après la livraison.

Écrivez la demande à partir d’un cas concret et daté plutôt qu’en termes généraux : la commande de tel client, celle qui a posé problème mardi. Un cas réel contient les détails que la formulation générale efface, et ce sont précisément ces détails qui font varier le prix d’un facteur cinq.

Enfin, une demande n’est pas une solution. « Ajouter un bouton pour exporter » est une solution ; « je dois donner cette liste au comptable chaque mois et je la recopie à la main » est une demande. La seconde autorise une réponse meilleure et moins chère que celle que vous auriez imaginée ; la première la ferme.

Bogue ou évolution : la frontière qui décide qui paie

C’est la source de tension la plus fréquente, et elle est presque toujours mal posée. La question n’est pas de savoir si le logiciel se comporte mal ; elle est de savoir s’il se comporte autrement que ce qui avait été convenu.

Un bogue est un écart avec ce qui était prévu : cela devait faire ceci, cela fait cela. Une évolution est un changement de ce qui était prévu, y compris quand le comportement actuel est manifestement gênant. Un logiciel qui fait exactement ce qui avait été demandé, et qui se révèle mal adapté à l’usage réel, ne contient pas de bogue — il contient une hypothèse fausse, ce qui est le sujet de la section 1.

Cette frontière n’est nette que si quelque chose écrit dit ce qui était prévu. Sans trace de la décision, chaque cas devient une négociation de bonne foi entre deux personnes qui se souviennent différemment, et la relation s’use sur des montants faibles.

La pratique qui règle cela ne coûte rien : à chaque livraison, une liste des règles décidées, en français, dans le même document où sont notées les demandes. Ce n’est pas de la documentation technique, c’est un compte rendu — et il sert autant à vous qu’au prestataire, y compris quand il vous donne tort.

La file d’attente, et pourquoi elle doit être visible

Dès qu’il y a plus d’un demandeur dans l’entreprise, il y a une file, et si personne ne la publie chacun suppose que sa demande est la prochaine. Le prestataire arbitre alors seul, souvent en prenant le plus facile ou le plus récent, et personne n’a décidé cela.

Une file visible est une liste que tout le monde peut lire, avec pour chaque demande son état — écrite, chiffrée, acceptée, en cours, livrée. Sa vertu n’est pas l’organisation, c’est qu’elle rend l’arbitrage explicite : quand deux demandes ne peuvent pas passer la même semaine, quelqu’un de chez vous choisit, et ce n’est plus le développeur qui choisit par défaut.

Elle change aussi la nature des relances. Sans elle, chaque demandeur relance individuellement, et la relance devient le mécanisme de priorisation — ce qui donne la priorité aux plus insistants plutôt qu’aux plus utiles. Avec elle, la question « où en est ma demande » a une réponse que personne n’a besoin de poser.

Une seule règle la garde utile : une demande n’entre dans la file qu’écrite selon les trois paragraphes de la section 3. Une file remplie de phrases d’une ligne ressemble à une liste de travail et n’en est pas une, parce qu’aucune de ses entrées ne peut être chiffrée sans une conversation.

La régression : le coût caché de chaque ajout

Un logiciel n’est pas une addition de fonctions indépendantes. Chaque ajout touche des règles existantes, et une partie du coût d’un changement est la vérification que le reste fonctionne encore. Cette part est invisible dans la demande et bien réelle dans le devis.

C’est ce qui explique un phénomène que tous les clients de logiciels sur mesure observent et attribuent d’ordinaire à la mauvaise volonté : la même demande, faite deux ans plus tard, coûte plus cher que si elle avait été faite au début. Le logiciel contient plus de règles à ne pas casser, et c’est tout.

Deux conséquences en découlent, et la seconde est contre-intuitive. La première est qu’il vaut mieux regrouper les changements qui touchent la même zone plutôt que de les demander un par un sur six mois. La seconde est qu’il est parfois moins cher de retirer une fonction que d’en ajouter une, parce qu’une règle en moins est une règle qui ne peut plus casser.

Cela donne aussi une bonne question à poser au moment du devis : quelle partie de ce prix est la modification elle-même, et quelle partie est la vérification du reste. Un prestataire qui sait répondre a compris son propre système ; un prestataire pour qui la question n’a pas de sens vous dit quelque chose.

Les environnements : pourquoi il en faut deux, et pas cinq

Il faut un endroit où le logiciel travaille pour de vrai, et un endroit où l’on peut essayer sans conséquence. Deux. C’est le minimum, et c’est presque toujours suffisant pour une entreprise qui n’édite pas de logiciel.

Sans le second, chaque essai se fait sur les vraies données, et la question « peut-on tester la nouvelle facturation » se termine par une facture réelle envoyée à un vrai client. C’est le genre d’incident qui n’arrive qu’une fois et qui coûte plus que la mise en place qu’il aurait fallu faire.

Le second sert aussi à autre chose que les tests du développeur : c’est là que vos propres équipes valident un changement avant qu’il ne devienne réel. Une validation faite par le prestataire seul valide que le code fait ce qu’il a compris, ce qui n’est pas la même chose que ce dont vous aviez besoin — c’est le sujet de la section 3 vu depuis l’autre bout.

Au-delà de deux, la complexité augmente plus vite que le bénéfice pour une organisation de cette taille : il faut alors maintenir les copies, les synchroniser, décider laquelle fait foi. C’est un problème d’éditeur de logiciel, pas d’utilisateur, et se le donner par imitation est une dépense sans contrepartie.

Le développeur unique, et ce qui se passe s’il part

La plupart des logiciels sur mesure d’une PME sont écrits par une personne, ou par deux. C’est la raison pour laquelle ils sont abordables, et c’est le risque principal du dispositif. Il ne se manifeste jamais progressivement : il se manifeste un lundi.

La bonne question n’est pas « comment éviter cela », parce qu’on ne l’évite pas. C’est « combien de temps faudrait-il à quelqu’un d’autre pour reprendre ». Une semaine est un risque acceptable ; trois mois est une dépendance dont il faut parler pendant que tout va bien, c’est-à-dire maintenant.

Trois choses font la différence entre les deux, et aucune n’est un document de trois cents pages. Le code est chez vous, dans un dépôt dont vous détenez l’accès. Il existe une note d’installation qui permet à un inconnu de faire tourner le système sur une machine neuve. Et les règles métier décidées sont écrites en français quelque part, ce qui est le compte rendu de la section 4.

Ces trois éléments ne rendent pas le départ indolore ; ils le rendent chiffrable. C’est le seul objectif raisonnable, et c’est aussi ce qui vous permet de rester chez un prestataire par choix plutôt que par impossibilité de partir.

Ce qu’il faut recevoir à chaque livraison

Une livraison n’est pas un fichier ou un message disant que c’est en ligne. Elle contient quatre choses, et les recevoir systématiquement coûte peu au prestataire tout en changeant complètement votre position.

La liste de ce qui a changé, en français, y compris ce qui a changé sans avoir été demandé. La liste des règles décidées en cours de route, celles de la section 4. La confirmation que le code livré est dans le dépôt qui vous appartient. Et ce qui reste à faire de connu, y compris les défauts acceptés temporairement.

Ce dernier point est le plus révélateur d’une relation saine. Tout logiciel en service contient des défauts connus et non corrigés, parce que corriger a un coût et que certains ne le valent pas. Les écrire est un signe de sérieux ; les taire produit la découverte au pire moment, généralement par un utilisateur.

Ces quatre éléments tiennent dans un message. Ils ne demandent pas d’outil, pas de méthode et pas de vocabulaire : ils demandent l’habitude, et c’est une habitude qui se prend à la première livraison ou jamais.

Le coût d’un changement de prestataire, honnêtement

Changer de prestataire sur un logiciel sur mesure n’est ni impossible ni indolore, et le chiffrer d’avance évite les deux erreurs habituelles : rester chez quelqu’un qui ne convient plus, ou partir en croyant que le coût est nul.

Le coût réel est presque entièrement de la lecture. Le nouveau prestataire doit comprendre un système qu’il n’a pas écrit, et cette période improductive dure d’autant plus longtemps que les trois éléments de la section 8 manquent. C’est un coût que vous payez au moment du changement mais qui a été décidé des années plus tôt.

Il y a un second coût, plus discret : pendant la reprise, les évolutions s’arrêtent presque complètement. Ce n’est pas une pause administrative, c’est que toucher un système qu’on ne comprend pas encore est le meilleur moyen de casser autre chose. Prévoyez cette période plutôt que de la découvrir.

Ce qui n’est pas un coût, en revanche, c’est le logiciel lui-même — à condition que le code vous appartienne et qu’il soit chez vous. Si cette condition n’est pas remplie, le changement de prestataire n’est pas cher : il est impossible, et c’est une situation différente qui se traite avant, pas au moment de partir.

Réécrire ou continuer : les trois signaux

Vient un moment où quelqu’un propose de tout refaire. C’est parfois juste et souvent prématuré, et l’envie est mauvais conseil dans les deux sens : un développeur préfère écrire, un dirigeant préfère ne pas repayer. Trois signaux valent mieux qu’une impression.

Le premier est le rapport entre le temps de comprendre et le temps de faire. Quand une modification d’une journée demande trois jours de lecture, ce n’est plus un logiciel qu’on fait évoluer, c’est un logiciel qu’on déchiffre — et ce rapport ne s’améliore jamais tout seul.

Le deuxième est la régression chronique : chaque changement en casse un autre, de façon répétée et non pas occasionnelle. Cela indique que les règles sont enchevêtrées plutôt que mal écrites, et l’enchevêtrement ne se corrige pas par petites touches.

Le troisième est l’environnement disparu : le système repose sur une version, une machine ou une bibliothèque qu’on ne peut plus obtenir ni mettre à jour. C’est le seul des trois qui impose un calendrier, parce qu’il transforme une décision en échéance. En dessous de deux de ces trois signaux, réécrire coûte presque toujours plus que ce qu’on croit économiser.

Ce que nous faisons, et ce que nous refusons

Notre part est le fonctionnement de cette période : la file visible et son arbitrage, la demande écrite en trois paragraphes, le compte rendu des règles décidées à chaque livraison, les deux environnements, et le dépôt de code qui vous appartient dès la première ligne. Ce sont des habitudes plus que des outils, et elles se prennent au début ou pas du tout.

Nous refusons de donner un prix moyen pour une évolution, et la raison n’est pas la prudence : il n’y a pas d’unité commune. Deux devis pour « la même » demande portent sur des objets différents, et un tarif affiché ne ferait que déplacer l’ambiguïté du devis vers la facture. Ce que nous chiffrons, c’est une demande écrite, et nous préférons passer une heure à l’écrire avec vous qu’à défendre un chiffre ensuite.

Nous refusons aussi de garder votre code. Il vit dans un dépôt à votre nom dès le premier jour, y compris quand cela ne vous intéresse pas encore et que c’est nous qui le réclamons. Un prestataire dont on ne peut pas partir n’est pas un prestataire fidèle, c’est un prestataire qui n’a plus besoin d’être bon — et nous ne voulons pas être dans cette position.

Enfin, la partie qui rapporte le plus vite ne demande aucun développement et ne nous demande rien : écrire vos trois prochaines demandes selon les trois paragraphes de la section 3, et demander à votre prestataire actuel combien de temps il faudrait à quelqu’un d’autre pour reprendre. La première fera baisser vos devis ; la seconde vous dira où vous en êtes.

Questions fréquentes

Pourquoi deux prestataires donnent-ils des prix si différents pour la même évolution ?

Parce qu’ils n’ont pas chiffré le même objet. « Ajouter une remise » peut vouloir dire un champ à saisir, ou cela plus les règles que la phrase implique — qui a le droit, jusqu’à quel plafond, ce que devient une facture déjà émise — ou cela plus la reprise de l’existant. Il n’y a pas de prix de marché pour une évolution parce qu’il n’y a pas d’unité commune. Écrivez la demande d’abord, comparez ensuite.

Comment savoir si c’est un bogue ou une évolution ?

La question n’est pas si le logiciel se comporte mal, mais s’il se comporte autrement que ce qui avait été convenu. Un écart avec le prévu est un bogue ; un changement du prévu est une évolution, même quand le comportement actuel gêne. Cette frontière n’est nette que si quelque chose d’écrit dit ce qui était prévu — d’où le compte rendu des règles à chaque livraison.

Pourquoi la même demande coûte-t-elle plus cher deux ans après ?

Parce qu’une partie du prix d’un changement est la vérification que le reste fonctionne encore, et que le logiciel contient désormais plus de règles à ne pas casser. Ce n’est pas de la mauvaise volonté. Deux conséquences utiles : regrouper les changements qui touchent la même zone, et se rappeler qu’il est parfois moins cher de retirer une fonction que d’en ajouter une.

Faut-il vraiment un second environnement ?

Oui, et deux suffisent. Sans lui, chaque essai se fait sur les vraies données et « peut-on tester la nouvelle facturation » finit par une facture réelle envoyée à un vrai client. Il sert aussi à vos équipes pour valider un changement avant qu’il ne devienne réel, ce que le prestataire ne peut pas faire à votre place. Au-delà de deux, la complexité dépasse le bénéfice pour une entreprise qui n’édite pas de logiciel.

Que faire si une seule personne connaît notre logiciel ?

On ne l’évite pas, on le rend chiffrable. La question utile est combien de temps il faudrait à quelqu’un d’autre pour reprendre : une semaine est acceptable, trois mois est une dépendance à traiter pendant que tout va bien. Trois choses font la différence — le code dans un dépôt qui vous appartient, une note d’installation utilisable par un inconnu, et les règles métier écrites en français.

Quand faut-il réécrire plutôt que continuer ?

Trois signaux, et il en faut au moins deux : une modification d’une journée qui demande trois jours de lecture ; une régression chronique où chaque changement en casse un autre de façon répétée ; et un environnement disparu, c’est-à-dire une version ou une machine qu’on ne peut plus obtenir. Seul le troisième impose un calendrier. En dessous de deux signaux, réécrire coûte presque toujours plus que ce qu’on croit économiser.

Où nous intervenons

Écrire votre prochaine demande en trois paragraphes — ce qui se passe aujourd’hui, ce que vous voudriez, ce que cela change ailleurs — ne coûte rien et change la réponse.

Nous rendons la file visible, avec ce qui passe devant et pourquoi.
Nous demandons la demande par écrit, y compris quand elle est urgente.
Nous versons votre code sous votre propre compte dès le premier jour.

Aucun prix moyen d’évolution ne vous sera donné : il n’en existe pas, parce qu’une même phrase peut coûter une heure ou trois semaines selon ce qu’elle touche.

Demander un devis, après audit En parler sur WhatsApp

À voir aussi

Parlons de votre projet

Un audit gratuit, sans engagement : nous regardons votre présence en ligne et nous vous disons ce qui coince.

Demander l’audit gratuit Nous écrire