En bref :
La plupart des produits numériques n'ont pas besoin d'une équipe de support à temps plein après leur lancement. Ils nécessitent une petite équipe dédiée, disponible sur contrat, qui surveille le système pendant les heures de bureau, corrige les éventuels problèmes et déploie les améliorations prévues par blocs planifiés. Prévoyez un budget annuel de 10 à 20 % du coût de développement pour assurer le maintien en condition opérationnelle du produit, et prévoyez un budget distinct pour les évolutions. Ce guide détaille ce que couvre cette maintenance, son coût et les modalités contractuelles.
Un produit numérique est un logiciel que vos clients utilisent ou achètent directement : une application web, une application mobile, une plateforme, une API, un service par abonnement ou une ressource téléchargeable comme un modèle, une formation ou un rapport. Rien de physique ne change de main. Pourtant, des serveurs, des dépendances, des navigateurs, des boutiques d'applications, des prestataires de paiement et des avis de sécurité sont toujours à l'œuvre, et tous évoluent, que vous touchiez ou non à votre code.
C'est cette différence qui prend les propriétaires de produits au dépourvu. Un produit physique est terminé une fois expédié. Un produit numérique ressemble davantage à un bateau à l'eau : la coque doit être nettoyée régulièrement, une fuite doit être colmatée dès son apparition, et l'installation d'une voile plus grande est un projet en soi. Le jour du lancement est celui où le bateau est mis à l'eau, pas celui où le travail s'arrête. Si vous vendez des produits numériques ou si vous en utilisez un comme moteur d'une activité de services, c'est le jour où les coûts de fonctionnement commencent.
Dès qu'un produit numérique est mis en ligne, les propriétaires se demandent comment il sera maintenu. C'est une préoccupation courante et justifiée. C'est à ce stade du cycle de vie que le produit a le plus besoin de support, et c'est aussi le moment où l'équipe d'ingénierie et de design se retire, car maintenir l'équipe complète n'est pas économiquement viable.
Les deux parties se retrouvent donc face à un problème. Le propriétaire du produit perd l'équipe qui possède le contexte, si bien que personne ne connaît le système lorsqu'une urgence survient. L'agence hérite de demandes de support régulières et imprévues qui arrivent alors que les mêmes personnes travaillent sur d'autres projets. Le changement de contexte en mode « pompiers », les délais qui glissent sur les nouveaux projets, et deux produits qui en pâtissent au lieu d'un.
Ce qu'il vous faut, c'est un arrangement équilibré : les propriétaires de produits disposent d'une équipe en cas de besoin, et les équipes projet ne sont pas constamment interrompues une fois le projet terminé. Pour concevoir cela, vous devez savoir ce qui doit réellement se passer une fois qu'un produit est livré.
Plusieurs tâches doivent être effectuées une fois qu'un produit est en ligne, durant ce que l'on appelle la phase de maintenance. Comprendre la nature de ces tâches est crucial, car chaque type est acheté, planifié et tarifié différemment. Elles sont généralement organisées comme suit :
Cette répartition n'est pas une invention de notre part. ISO/IEC/IEEE 14764:2022, la norme internationale pour la maintenance logicielle, formalise le travail post-livraison en quatre catégories : corrective, adaptative, perfective et préventive. Notre modèle en trois axes s'y aligne directement. La maintenance préventive reste préventive, la corrective reste corrective, et nous regroupons les deux types d'amélioration, adaptative et perfective, en un seul axe que nous appelons évolutive, car sur le plan commercial, elles sont achetées et planifiées de la même manière.
Les recherches à l'origine de cette norme s'accordent sur un point qui surprend la plupart des propriétaires de produits : la majeure partie des efforts de maintenance est consacrée à l'amélioration, et non à la correction de défauts. Dans l'étude classique de Lientz, Swanson et Tompkins, le travail perfectif, c'est-à-dire l'amélioration, représentait à lui seul environ 60 % des efforts de maintenance, tandis que la correction de bugs représentait moins d'un cinquième. Ce constat a été confirmé à maintes reprises depuis.
Chez Imaginary Cloud, nous gérons ces trois types de maintenance comme trois axes distincts dans ce que nous appelons un contrat en trois axes : une ligne contractuelle pour le préventif, une pour le correctif et une pour l'évolutif, chacune étant tarifiée et planifiée indépendamment plutôt que puisée dans un réservoir d'heures unique.
Pourquoi les séparer ? Parce que ces trois types de maintenance se comportent différemment. Le travail préventif est prévisible et peut être planifié. Le travail correctif est imprévisible et nécessite un engagement de réactivité. Le travail évolutif se planifie comme n'importe quel autre projet. Selon notre expérience, un réservoir d'heures indifférencié est la raison habituelle pour laquelle un budget de maintenance s'épuise prématurément dans l'année : un incident au premier trimestre consomme les heures destinées à couvrir douze mois de correctifs, et les améliorations prévues sont les premières à passer à la trappe.
Dans toute situation relevant de la maintenance préventive ou corrective, le propriétaire du produit a besoin d'une équipe pour gérer les problèmes existants. Cependant, la majorité des produits numériques ne nécessitent pas une équipe disponible 24h/24 et 7j/7. Ce dont ils ont besoin, c'est d'une équipe qui surveille le système et intervient en cas de défaillance. Avec des mesures appropriées, l'infrastructure moderne est suffisamment stable pour qu'une assistance durant les heures de bureau suffise à la plupart des produits.
Le temps consacré à la maintenance est généralement contractualisé via un forfait : une redevance mensuelle fixe qui réserve un volume d'heures convenu auprès d'une équipe dédiée, que vous utilisiez ou non la totalité de ce temps sur le mois. Vous payez autant pour la disponibilité et la connaissance du contexte que pour les heures de travail. Pour optimiser ce modèle, l'équipe assure le suivi de plusieurs produits simultanément et applique des processus standardisés pour des services tels que la surveillance des serveurs et les correctifs de sécurité.
Dans certains cas, une assistance 24h/24 et 7j/7 est nécessaire, ce qui constitue un service totalement différent. Attendez-vous à payer un supplément, généralement auprès d'une entreprise spécialisée dans les contrats de maintenance, car cela exige une gestion des rotations et des procédures d'escalade qui ne sont viables qu'à une échelle beaucoup plus importante.
La ligne corrective est celle où les temps de réponse sont définis ; le manque de précision à ce stade est souvent source de conflits ultérieurs. Un accord de niveau de service (SLA) efficace précise trois éléments pour chaque niveau de gravité : le délai d'accusé de réception du signalement, le délai de début d'intervention, et l'objectif de résolution ou de solution de contournement. Une structure courante pour un forfait aux heures de bureau se présente comme suit :
| Sévérité | Exemple | Accusé de réception | Résolution cible |
|---|---|---|---|
| Critique | Produit indisponible, échec du paiement, données en danger | Sous 1 heure ouvrée | Le jour ouvrable même, solution de contournement d'abord |
| Élevée | Fonctionnalité clé défectueuse pour de nombreux utilisateurs | Sous 4 heures ouvrées | Le jour ouvrable suivant |
| Moyenne | Défaut non critique, une solution de contournement existe | Sous 1 jour ouvrable | Prochaine version planifiée |
| Faible | Problème cosmétique, modification mineure de contenu | Sous 2 jours ouvrables | Regroupé dans les travaux planifiés |
Définissez les niveaux de gravité avant de signer, et non lors de votre premier incident. Convenez de qui est habilité à déclarer un problème critique. Déterminez également ce qu'il advient du travail prévu pour le mois lorsqu'un tel incident survient.
L'assistance aux heures de bureau n'est viable que si le système vous alerte lui-même en cas de problème, plutôt que d'attendre qu'un client ne le signale. Une base de surveillance efficace couvre la disponibilité et les tests de points de terminaison, le suivi des erreurs avec alertes, l'agrégation des journaux, les métriques d'infrastructure (CPU, mémoire, disque), les performances de la base de données et les requêtes lentes, la vérification des sauvegardes avec tests de restauration, ainsi que l'analyse des dépendances et des vulnérabilités par rapport aux avis publics tels que la National Vulnerability Database et les recommandations publiées par OWASP.
C'est ce dernier point qui transforme la maintenance préventive d'un simple exercice calendaire en une véritable protection. Lorsqu'une vulnérabilité est révélée dans un framework dont vous dépendez, la question n'est pas de savoir si vous allez appliquer le correctif, mais combien de jours s'écouleront avant que vous ne soyez au courant de son existence.
La maintenance évolutive est principalement axée sur la croissance de l'entreprise et l'amélioration des services ; elle peut être planifiée et exécutée en temps opportun. Dressez une liste de tâches, puis demandez à votre partenaire technologique de constituer une équipe pour les traiter en quelques sprints : des blocs de développement fixes, d'une durée généralement d'une ou deux semaines chacun, avec un périmètre défini au départ et une livraison à l'arrivée.
Isoler le travail évolutif dans des sprints planifiés, plutôt que de le laisser s'infiltrer via le canal de support, protège les deux parties. Le propriétaire du produit bénéficie d'un rythme de livraison prévisible et d'un coût visible par bloc. L'équipe peut planifier sa capacité, ce qui signifie concrètement que personne n'est détourné d'un autre projet au pied levé. Consultez Waterfall vs Agile : quand utiliser chaque méthode pour comparer ces deux styles de planification lors de la structuration de vos blocs.
C'est également ici que se situent les travaux de croissance. Réarchitecturer un produit pour qu'il puisse supporter davantage d'utilisateurs est un projet évolutif classique : nous avons reconstruit l'expérience de création d'applications de GoodBarber sur une architecture plus évolutive exactement de cette manière, comme vous pouvez le découvrir dans l' étude de cas GoodBarber Composer.
Le principal facteur de coût de l'évolution n'est pas la taille de la fonctionnalité, mais la difficulté à modifier la base de code existante. Cette difficulté porte un nom, la dette technique, et si elle n'est pas gérée, elle gonfle silencieusement chaque amélioration que vous déployez. Robert Glass l'a souligné il y a des décennies : la tâche dominante dans la maintenance consiste à comprendre le produit existant avant de pouvoir y toucher en toute sécurité.
La façon de garder ce coût visible est de le mesurer. Un audit de code périodique, qui évalue la maintenabilité, la complexité et la couverture des tests, vous indique où se situe la dette avant qu'elle ne fasse dérailler une version. Nous avons produit une documentation en pseudocode de 195 modèles pour GoodBarber, décrite dans l' étude de cas sur la standardisation du code, afin qu'ils puissent prendre des décisions architecturales basées sur des preuves plutôt que sur des suppositions avant une reconstruction majeure. Pour une vue d'ensemble, notre guide sur la gestion de la dette technique présente les options pratiques.
Les produits numériques ne constituent pas une catégorie commerciale unique. La manière dont le vôtre génère des revenus détermine le coût de vos temps d'arrêt, la rapidité avec laquelle vous devez appliquer des correctifs et la charge pesant sur chacune des trois lignes de maintenance. Cinq modèles couvrent la majeure partie du marché.
L'utilité pratique de cette liste réside dans le dimensionnement. Déterminez d'abord le coût d'une heure d'interruption pour votre modèle, puis choisissez le contrat de maintenance correspondant. Une place de marché à fort volume de transactions et une boutique de modèles réalisant cinquante ventes par mois sont toutes deux des produits numériques, mais elles ne devraient pas souscrire au même niveau de support.
Après le lancement, le réflexe naturel est de dimensionner l'équipe en fonction du pire mois. C'est ce qui rend la maintenance financièrement inaccessible, et c'est un mauvais calcul, car le pire mois n'est pas le mois moyen.
Pour la plupart des produits durant leur première année, une structure pertinente consiste à privilégier une équipe fractionnée plutôt qu'une équipe dédiée : un ingénieur à temps partiel qui maîtrise le contexte du produit, un ingénieur DevOps ou plateforme à temps partiel pour l'infrastructure et le monitoring, ainsi qu'un accès ponctuel à un designer et à un lead pour les évolutions. Cela représente une fraction du coût d'un équivalent temps plein, tout en étant plus efficace qu'un junior dédié en termes de disponibilité, car cela couvre les congés, les absences et les expertises qu'une seule personne ne peut posséder. Lorsqu'un produit dispose de sa propre squad, le modèle intégré fonctionne également très bien : nous avons rejoint l'équipe d'AppTweak en tant qu'unité frontend intégrée, en suivant leurs propres processus. Trois modèles contractuels couvrent la quasi-totalité des situations :
| Modèle | Ce que vous obtenez | Idéal pour |
|---|---|---|
| Forfait heures ouvrables | Frais mensuels fixes, volume d'heures convenu, engagement de réponse pendant les heures de travail. Les heures non utilisées sont généralement plafonnées et non reportables. | La plupart des produits ; le modèle pour lequel le forfait de base est conçu |
| Temps et matériaux (Régie) | Payez ce que vous utilisez, pas de garantie de disponibilité. Le moins cher sur le papier, le plus coûteux lors d'un incident, car vous rejoignez la file d'attente. | Outils internes, faible exposition commerciale |
| Couverture 24/7 ou étendue | Personnel de roulement, escalade d'astreinte, tarification premium. | Plateformes transactionnelles, services réglementés ou critiques pour la sécurité |
Déterminez l'option à choisir en évaluant le coût d'une heure d'interruption de service, plutôt qu'en vous focalisant sur le coût de l'abonnement. Les entreprises qui vendent des produits numériques en continu, plutôt que par cycles de projet, constatent presque toujours que l'abonnement est l'option la plus économique.
Pour les produits que nous développons puis accompagnons, la maintenance préventive et corrective représente 10 à 20 % du coût de conception initial par an ; c'est la fourchette que nous prévoyons dans nos budgets avec nos clients. Cela correspond aux études générales sur les coûts du cycle de vie des logiciels : Robert Glass estime que la maintenance représente 40 à 80 % du coût total du cycle de vie, avec une moyenne de 60 %, dans Facts and Fallacies of Software Engineering (2002), ce qui, sur la durée de vie d'un produit, représente un montant supérieur à celui de sa conception initiale.
Concrètement : pour un produit dont la conception a coûté 150 000 £, il faut prévoir un budget annuel d'environ 15 000 à 30 000 £ pour assurer son fonctionnement, hors ajout de nouvelles fonctionnalités. Votre position dans cette fourchette dépend du modèle commercial choisi, du nombre d'intégrations tierces et de la part de la pile technique que vous maîtrisez.
La maintenance évolutive ne fait pas partie de ce montant, car elle est liée à la croissance du produit. Considérez-la comme une ligne budgétaire distincte, la troisième ligne de votre contrat de maintenance, et dimensionnez-la en fonction de votre feuille de route plutôt que du coût de conception. Un produit en phase de croissance active peut facilement générer des coûts de maintenance évolutive annuels supérieurs au cumul des coûts de maintenance préventive et corrective.
Deux types de coûts sont régulièrement oubliés lors de l'établissement du premier budget, mais finissent toujours par apparaître : les services tiers (hébergement, surveillance, suivi des erreurs et API payantes), ainsi que les frais liés aux boutiques d'applications et à la conformité, nécessaires pour maintenir une application mobile publiable à mesure que les plateformes font évoluer leurs exigences.
Travaillez sur ces réponses dès le premier jour avec votre partenaire de développement logiciel. Exprimez clairement vos préoccupations et définissez contractuellement la marche à suivre en cas de problème, plutôt que de miser sur la bonne volonté. Cela vous évitera de vous retrouver, après le lancement, face à une situation insoluble sans conflit ; et lorsque cela arrive, ce sont vos utilisateurs qui en pâtissent en premier, avec des conséquences directes sur votre activité.
Il s'agit d'un élément utilisé ou acheté par les clients sans aucun échange physique : une application web ou mobile, une plateforme, une API, un service d'abonnement ou une ressource téléchargeable telle qu'un modèle, une formation ou un rapport. Tous dépendent d'infrastructures, de services tiers et de bibliothèques de code en constante évolution, ce qui explique pourquoi chaque produit numérique engendre des coûts de fonctionnement après son lancement.
Prévoyez un budget annuel de 10 à 20 % du coût de développement initial pour la maintenance préventive et corrective. Un produit dont la création a coûté 150 000 £ nécessite environ 15 000 à 30 000 £ par an. La maintenance évolutive, qui concerne les nouvelles fonctionnalités et le développement, fait l'objet d'un budget distinct basé sur votre feuille de route.
La plupart n'en ont pas besoin. Avec une surveillance, des alertes et un contrat de maintenance aux heures de bureau, la majorité des produits sont suffisamment couverts. Une assistance permanente se justifie uniquement lorsqu'une heure d'interruption entraîne un coût direct en termes de revenus, de réglementation ou de sécurité ; elle est généralement souscrite auprès d'une entreprise spécialisée dans les contrats de maintenance.
Il s'agit des travaux visant à améliorer ou à étendre un produit existant plutôt qu'à assurer son simple fonctionnement : nouvelles fonctionnalités, réécriture pour la performance, ajout de capacité, intégrations. Cela correspond à ce que la norme ISO 14764 appelle la maintenance adaptative et perfective. Ces travaux sont déployés par sprints, comme tout autre développement, et doivent faire l'objet d'un contrat et d'un budget distincts de l'assistance.
La maintenance préventive est une intervention planifiée visant à éviter les pannes, comme l'application de mises à jour de sécurité ou le renouvellement de certificats. La maintenance corrective est une intervention réactive après une défaillance, comme la restauration d'un serveur en panne. Le travail préventif est prévisible et planifiable, tandis que le travail correctif nécessite un engagement sur les délais de réponse.
Une équipe dédiée, un forfait d'heures mensuel convenu, des objectifs de réponse et de résolution selon la gravité, une configuration définie de surveillance et d'alertes, une fréquence de déploiement des correctifs, ainsi qu'un processus clair sur la gestion des tâches planifiées en cas d'incident critique, incluant les personnes habilitées à le déclarer.
Moins d'ingénierie qu'un produit SaaS, mais la surface commerciale doit tout de même être maintenue : tunnel de commande, intégrations de prestataires de paiement, livraison de licences, hébergement de fichiers et contrôle d'accès. La majeure partie du risque réside dans la maintenance préventive, car les éléments les plus susceptibles de tomber en panne sont les services tiers qui évoluent selon leur propre calendrier.
C'est possible, et cela devient pertinent une fois que le produit est suffisamment important pour occuper une équipe à temps plein. En dessous de ce seuil, une équipe externalisée permet de couvrir les congés, les absences et d'apporter des expertises qu'un seul employé interne ne pourrait offrir, le tout pour un coût généralement inférieur à un salaire à temps plein.
Si votre produit est proche du lancement, ou s'il est déjà en ligne et bénéficie d'un support informel, il est judicieux de formaliser cet arrangement avant qu'un incident ne vous y oblige. Notre équipe peut examiner votre configuration actuelle et vous proposer une solution de maintenance adaptée aux risques réels de votre produit, plutôt qu'au pire scénario.
Discutez avec nous de votre support post-lancement et nous vous expliquerons les besoins de votre produit ainsi que les coûts associés. Vous pouvez réserver un appel ici.
CEO @ Imaginary Cloud et co-auteur du livre Product Design Process. J'aime la nourriture, le vin et le Krav Maga (pas nécessairement dans cet ordre).
Alexandra Mendes est spécialiste senior de la croissance chez Imaginary Cloud et possède plus de 3 ans d'expérience dans la rédaction de textes sur le développement de logiciels, l'IA et la transformation numérique. Après avoir suivi un cours de développement frontend, Alexandra a acquis des compétences pratiques en matière de codage et travaille désormais en étroite collaboration avec les équipes techniques. Passionnée par la façon dont les nouvelles technologies façonnent les entreprises et la société, Alexandra aime transformer des sujets complexes en contenus clairs et utiles pour les décideurs.
People who read this post, also found these interesting:
.webp)
