Personne ne pose la question de la maintenance avant de signer. Tout le monde panique six mois après le lancement.
Un logiciel sur mesure n'est pas un achat unique. C'est un système vivant qui a besoin d'hébergement, de correctifs de sécurité, de corrections de bugs, de monitoring, et de développement continu au fil de l'évolution de votre entreprise. L'agence qui l'a construit ne le maintiendra pas gratuitement. Et si vous n'avez pas de plan, vous le découvrirez de la pire façon — généralement quand quelque chose casse un vendredi soir.
Cet article couvre ce que la maintenance logicielle signifie réellement, combien elle coûte, et les trois modèles pour la gérer. Si vous êtes sur le point de commander un projet sur mesure, lisez ceci avant de signer — pas après le lancement.
Ce que la « maintenance » inclut vraiment
Quand les gens entendent « maintenance », ils pensent corrections de bugs. C'est peut-être 20 % du total. Le reste est moins visible mais tout aussi critique.
Hébergement et infrastructure. Votre application tourne sur des serveurs. Ces serveurs ont besoin de monitoring, de scaling, de sauvegardes, et de changements de configuration occasionnels. Si vous êtes sur une plateforme managée comme Laravel Forge ou AWS, une partie est automatisée — mais quelqu'un doit quand même surveiller.
Mises à jour de sécurité. Le framework, le langage de programmation, le système d'exploitation du serveur, et chaque package tiers dont dépend votre application publient des correctifs de sécurité régulièrement. Les appliquer n'est pas optionnel. Les ignorer transforme votre application en cible. Ce n'est pas théorique — les dépendances non patchées sont le vecteur d'attaque le plus courant pour les applications web.
Corrections de bugs. Aucun logiciel ne sort sans bugs. Certains apparaissent immédiatement. D'autres émergent des semaines ou des mois plus tard quand les utilisateurs rencontrent des cas limites que personne n'a testés. Vous avez besoin de quelqu'un disponible pour diagnostiquer et corriger — idéalement avant que vos utilisateurs ne signalent le problème.
Monitoring des performances. Les applications ralentissent avec le temps à mesure que les données grandissent, que les patterns d'utilisation changent, et que l'infrastructure vieillit. Sans monitoring, vous ne remarquerez le ralentissement que quand les utilisateurs se plaindront. Avec le monitoring, vous le détectez tôt et optimisez avant que ça devienne un problème.
Petites demandes d'évolution. Votre business change. Une nouvelle réglementation exige un champ supplémentaire. Une restructuration d'équipe implique de nouveaux rôles utilisateurs. Un client demande un format d'export que vous n'aviez pas prévu. Ce ne sont pas de nouveaux projets — c'est l'évolution naturelle d'un système vivant.
Mises à jour des dépendances. Le framework sort une nouvelle version majeure. Une API tierce que vous avez intégrée change ses endpoints. Un prestataire de paiement déprécie le SDK que vous utilisez. Garder votre application compatible avec le monde qui l'entoure est un travail continu.
Combien coûte la maintenance
Le standard de l'industrie est 15-25 % du coût de développement initial par an. C'est un benchmark utile, mais ça varie selon la complexité de votre application, le nombre d'utilisateurs, et la vitesse d'évolution de votre business.
Pour un projet qui a coûté 100K € à construire, prévoyez 15K-25K € par an en maintenance — couvrant l'hébergement, les mises à jour de sécurité, les corrections de bugs, le monitoring, et les petites évolutions. Soit environ 1 200-2 000 € par mois.
Ce chiffre surprend beaucoup de clients. Mais considérez l'alternative : si votre application tombe pendant une journée parce que personne n'a appliqué un correctif de sécurité, ou si vous perdez des données parce que personne ne surveillait les sauvegardes, le coût de cet incident dépassera une année de maintenance.
La maintenance la moins chère est la maintenance proactive. La plus chère est de réparer quelque chose qui a cassé parce que personne ne surveillait.
Trois modèles de maintenance
Modèle 1 : Le contrat de maintenance avec l'agence
Vous gardez un forfait mensuel avec l'agence qui a construit le logiciel. Elle gère l'hébergement, le monitoring, les mises à jour de sécurité, les corrections de bugs, et les petites évolutions dans le cadre du forfait. Les développements plus importants sont cadrés et facturés séparément.
Quand ça marche : Quand vous n'avez pas d'équipe technique interne et voulez un point de responsabilité unique. L'agence connaît le code, connaît les décisions d'architecture, et peut réagir rapidement parce qu'elle a tout construit.
Le risque : La dépendance envers l'agence. Si la relation se détériore, ou si l'agence ferme ou change de priorités, il faut transitionner — c'est pourquoi la propriété du code et la documentation sont si importants à la livraison.
C'est le modèle que la plupart de nos clients utilisent avec nous. On propose des forfaits mensuels qui couvrent la maintenance proactive (monitoring, mises à jour, sauvegardes) plus une banque d'heures pour les corrections et petits changements.
Modèle 2 : Équipe interne
Vous recrutez un ou plusieurs développeurs pour maintenir le logiciel en interne. Ils gèrent les opérations quotidiennes, les corrections de bugs, et le développement incrémental.
Quand ça marche : Quand le logiciel est au cœur de votre activité, quand vous avez assez de travail de développement continu pour justifier un poste à temps plein, et quand vous pouvez recruter quelqu'un avec les bonnes compétences.
Le risque : Il faut trouver quelqu'un capable de travailler avec le code existant — c'est pourquoi le choix technologique compte. On a expliqué pourquoi on construit avec Laravel précisément parce que le vivier de talents rend le recrutement interne réaliste. Essayez de recruter un développeur Elixir en interne pour une entreprise de taille moyenne et vous comprendrez le problème.
Si vous prévoyez cette option, assurez-vous que votre agence livre une documentation correcte, du code propre, et une session de passation. Sans ça, votre nouvelle recrue passera ses trois premiers mois juste à comprendre ce qui a été construit.
Modèle 3 : Personne
Vous lancez le logiciel et espérez que rien ne casse.
Quand ça marche : Jamais.
On a hérité de projets de clients qui ont essayé. Le schéma est toujours le même : l'application fonctionne bien pendant 6-12 mois. Puis une vulnérabilité de sécurité est publiée pour une dépendance non patchée. Ou le certificat SSL expire et le site tombe. Ou le serveur manque d'espace disque parce que personne n'a configuré la rotation des logs. Ou un prestataire de paiement met à jour son API et les transactions commencent silencieusement à échouer.
Le coût de « pas de maintenance » n'est pas zéro — il est différé. Et la maintenance différée coûte toujours plus que la maintenance proactive parce qu'on répare une crise au lieu de la prévenir.
Ce qu'il faut négocier avant le lancement
Si vous êtes en train de commander un logiciel sur mesure — ou sur le point de signer avec une agence — mettez la maintenance sur la table maintenant. Pas après le lancement. Voici ce qu'il faut clarifier :
Qui est propriétaire du code ? Vous devriez l'être. Propriété complète, dans un dépôt Git, avec documentation. Ça garantit que vous pouvez changer de prestataire ou internaliser la maintenance si besoin. On en a parlé dans notre article sur comment on livre les projets — la propriété du code est non négociable chez nous.
Que comprend le contrat de maintenance ? Obtenez des détails. « Support continu » est vague. Est-ce que ça inclut l'hébergement ? Le monitoring ? Combien d'heures de corrections par mois ? Quel est le temps de réponse pour les incidents critiques ? Qu'est-ce qui est facturé en plus ?
Quel est l'engagement de temps de réponse ? Si votre application tombe à 14h un mardi, en combien de temps quelqu'un répondra ? Ça doit être écrit, pas supposé.
Que se passe-t-il si on dépasse le forfait ? Si votre application croît significativement, le périmètre de maintenance devra croître aussi. Comprenez comment le forfait évolue — prix annuel fixe, ou ajusté selon l'usage et la complexité.
Que se passe-t-il si on veut partir ? Si vous décidez de changer d'agence ou d'internaliser la maintenance, à quoi ressemble la transition ? Une bonne agence rendra ça facile parce qu'elle vous a déjà donné le code, la documentation, et les connaissances.
La conversation maintenance est un signal de confiance
Voici ce qu'on a remarqué : les agences qui évitent la conversation maintenance pendant le processus commercial sont généralement les mêmes qui livrent du code non documenté, résistent à transmettre le dépôt, et créent de la dépendance par design.
Une agence qui aborde la maintenance de manière proactive — qui explique les coûts, propose des options de forfait claires, et s'assure que vous pouvez partir si vous le souhaitez — est une agence qui pense à la santé long terme de votre projet, pas juste à closer le deal.
Utilisez ceci comme filtre quand vous évaluez des agences. Demandez-leur : « Que se passe-t-il après le lancement ? » Si la réponse est vague, ça vous dit tout.
On a écrit sur comment rédiger un brief, comment fonctionnent les modèles de tarification, et combien de temps prennent les projets. La maintenance est la dernière pièce — celle qui détermine si votre investissement continue à créer de la valeur ou se détériore lentement.
Vous planifiez un projet et voulez comprendre le coût total du cycle de vie ? Parlons-en →