
Agence de développement logiciel : le coût de possession, pas le coût de livraison
Un devis de développement chiffre la livraison. Le coût réel est celui de la possession sur trois ans. Les cinq postes invisibles, et comment les faire écrire.
Un devis de développement logiciel chiffre la livraison ; le coût réel est celui de la possession sur trois ans, qui comprend cinq postes n'apparaissant sur aucun devis : la maintenance corrective, la mise à jour des dépendances, les montées de version des services tiers, l'astreinte, et le remboursement de la dette technique.
Sur un projet d'application métier, ces postes représentent couramment autant que le développement initial, étalés sur trois ans. Voici comment les faire chiffrer avant de signer.

Poste 1, La maintenance corrective
Les bugs découverts après la mise en production. Ils existent toujours, et l'important n'est pas de les nier mais de savoir qui les corrige, dans quel délai et à quel prix.
Ce qu'il faut faire écrire : la durée de la garantie sur les anomalies, la définition de ce qui est une anomalie par opposition à une évolution, et le délai d'intervention.
Le piège classique : une garantie de trois mois qui expire précisément au moment où les utilisateurs commencent réellement à se servir du produit. Une garantie utile court à partir de la mise en service effective, pas de la livraison.
Poste 2, La mise à jour des dépendances
Un projet moderne repose sur des centaines de bibliothèques tierces. Elles publient des correctifs de sécurité, se déprécient, et parfois cessent d'être maintenues.
Le coût réel : quelques jours par an sur un projet sain, beaucoup plus sur un projet laissé deux ans sans mise à jour, parce que les sauts de versions s'accumulent et deviennent des chantiers.
Ce qu'il faut faire écrire : qui surveille les alertes de sécurité, à quelle fréquence les dépendances sont mises à jour, et si c'est inclus ou facturé.
Le signal : une agence qui n'a pas de réponse à cette question livre des projets qu'elle ne maintient pas.
Poste 3, Les montées de version des services tiers
Votre logiciel s'appuie sur des services externes : paiement, envoi d'e-mails, authentification, hébergement. Chacun fait évoluer ses interfaces et en abandonne d'anciennes, avec un préavis.
Le coût réel : imprévisible dans le détail, prévisible dans le principe. Sur trois ans, tablez sur plusieurs interventions.
Ce qu'il faut faire écrire : la liste des services tiers utilisés, avec pour chacun l'engagement de compatibilité. C'est aussi la liste de vos dépendances commerciales, utile à connaître pour d'autres raisons.

Poste 4, L'astreinte
La question à poser : que se passe-t-il si le système tombe un samedi à 3 h du matin ?
Trois réponses possibles, trois prix très différents. Rien avant lundi, acceptable pour un outil interne. Un engagement d'intervention en heures ouvrées, le cas le plus courant. Une astreinte réelle 24 h / 24, coûteuse, et rarement justifiée avant d'avoir des clients qui la réclament.
L'erreur symétrique : payer une astreinte dont vous n'avez pas besoin, ou découvrir que vous n'en avez pas quand vous en auriez besoin. Les deux se règlent en posant la question au moment du devis.
Poste 5, La dette technique
C'est le poste le plus important et le seul dont personne ne parle en avant-vente.
Toute décision prise pour livrer plus vite crée une dette : un contournement, une abstraction manquante, un test non écrit. Ce n'est pas un défaut, c'est un arbitrage souvent rationnel. Le problème n'est pas de créer de la dette, c'est de ne jamais la rembourser.
Le symptôme mesurable : le temps nécessaire pour ajouter une fonctionnalité comparable augmente au fil des mois. Si une fonctionnalité qui prenait trois jours en prend huit un an plus tard, vous payez des intérêts.
Ce qu'il faut prévoir : une part du budget récurrent, de l'ordre de 15 à 20 % du temps de développement, consacrée à rembourser plutôt qu'à ajouter. Une agence qui refuse ce principe vous vendra beaucoup de fonctionnalités et un système de plus en plus lent à faire évoluer.
Le devis à demander
Plutôt qu'un prix de livraison, demandez trois lignes.
Le coût de construction, avec le périmètre associé.
Le coût de possession annuel, avec le détail des cinq postes ci-dessus.
Le coût de reprise : combien coûterait à une autre équipe de reprendre ce projet, et qu'est-ce qui est fait pour que ce coût reste bas, documentation, tests, pile technique répandue.
Une agence qui répond aux trois est une agence qui a déjà exploité ce qu'elle a construit. Une agence qui ne répond qu'à la première n'a peut-être jamais vu ses projets vieillir.
Ce que nous faisons chez Cod'Hash
Nous développons et nous exploitons nos propres produits, CodMenu, La Brigade, CodAgents. Ce n'est pas un argument commercial mais une contrainte : nous payons nous-mêmes les cinq postes ci-dessus sur notre propre code, ce qui nous rend particulièrement peu enclins à écrire du code que nous devrons subir.
Ce que cela donne concrètement : des piles techniques volontairement répandues, TypeScript, React, Next.js, PostgreSQL,, des tests sur les parcours critiques, et une préférence assumée pour la solution ennuyeuse quand elle suffit.
Notre limite, avouée : nous sommes une petite équipe. Sur un projet exigeant plus de cinq développeurs en parallèle, ou une astreinte permanente contractualisée, nous ne sommes pas le bon choix, et nous le disons plutôt que de sous-traiter en cascade.
Questions fréquentes
Combien coûte la maintenance d'un logiciel ? Une fourchette souvent citée dans l'industrie situe la maintenance annuelle entre 15 et 25 % du coût de développement initial. Le chiffre varie beaucoup selon le nombre d'intégrations tierces : faites-le chiffrer poste par poste plutôt que d'appliquer un pourcentage.
Peut-on développer sans maintenance ? Non, sauf pour un logiciel destiné à être abandonné. Les correctifs de sécurité des dépendances suffisent à eux seuls à imposer un rythme minimal.
Comment savoir si une agence produit de la dette ? Demandez le temps qu'a pris leur dernière fonctionnalité comparable à celle du début du projet. S'ils ne mesurent pas, c'est déjà une réponse.
Faut-il internaliser après la construction ? C'est souvent la bonne trajectoire, à condition que le code soit repris par quelqu'un, pas seulement transféré. Prévoyez un recouvrement de deux à trois mois entre l'agence et l'équipe interne.
---
Nous portons les astreintes de ce que nous écrivons, ce qui nous rend prudents sur ce que nous écrivons. Pour en discuter, écrivez-nous. Les vérifications contractuelles sont dans agence de développement sur mesure.