Exploitation, maintenance et services pour ton produit numérique

Un logiciel développé sur mesure ne doit pas seulement faire l'objet d'améliorations constantes, mais nécessite également une maintenance et, dans la plupart des cas, une assistance et un service après-vente. Dans un monde en constante évolution, les variables techniques, les exigences d'utilisation et les attentes des utilisateurs changent. Les systèmes d'exploitation ont besoin de sauvegardes, les certificats doivent être renouvelés – et des problèmes inattendus peuvent survenir à tout moment. Tout cela rend indispensable la gestion continue d'une application ou d'un site web.

Tu as un problème urgent ?

Clique ici pour accéder à nos coordonnées pour l'assistance et les demandes générales.

Les éléments constitutifs d'un SLA

  • Définition et limites du système : De quel produit s'agit-il quels composants sont pris en compte dans l’accord ? Par exemple : le serveur X, le système de gestion de contenu (CMS) Y et l’application Android Z.

  • Responsabilités : Qui fait quoi ? Autrement dit, quelles sont les tâches qui te reviennent, à ton équipe ou à ton entreprise, et que fait Apps with love ? Où interviennent d'éventuels tiers ? Il est capital d'y voir clair sur ces questions pour garantir une exploitation efficace. C’est pourquoi nous réglons cela en détail dans une matrice RACI. Celle-ci définit pour chaque aspect :

    • Qui réalise la tâche (Responsible)

    • Qui décide et valide (Accountable)

    • Qui est consulté (Consulted)

    • Qui doit être informé (Informed)

De plus, cette matrice précise si les prestations correspondantes sont incluses dans un forfait ou si elles sont facturées au temps et au matériel (Time & Material, T&M). Tu trouveras ci-dessous un exemple de matrice RACI.

  • Délais de réaction en cas de support ou d'incident : Nous définissons la rapidité avec laquelle tu peux attendre une réponse de notre équipe de support et le temps qu'il nous faut pour commencer à travailler sur une solution.

  • Fonctionnement du processus de support : Cela comprend bien entendu la désignation des personnes ou équipes responsables ainsi que leurs coordonnées.

  • Quels sont les coûts et quelles options supplémentaires sont incluses dans le contrat ?

Comment définir ensemble les délais de réponse

Le SLA définit les attentes fondamentales applicables dans chaque cas : les délais d'intervention sont fixés en fonction de la gravité du problème.

Le niveau de gravité est déterminé par l'urgence et l'impact du problème sur notre cliente. Les délais de réponse définissent le temps maximal dont nous disposons pour traiter chaque incident.

Si, par exemple, une application ne peut plus être lancée sur aucun appareil, cela revêt à la fois un caractère urgent et un impact important. Il s'agit d'un incident bloquant. Dans cet exemple de SLA, les délais de réponse et d'intervention pour un incident bloquant ont été fixés respectivement à 4 et 8 heures maximum.

Matrice permettant de hiérarchiser les incidents selon deux axes : l'urgence (faible à élevée) et l'impact (faible à élevé)
Matrice permettant de déterminer la priorité (gravité) d'un incident
Tableau d'exemple indiquant les délais de réponse et d'intervention pour les incidents de différentes priorités. Ces délais vont de « au mieux » à « 4 heures maximum » pour les incidents dont la priorité va de « Faible » à « Bloquant ».
Exemple d'accord sur les délais de réponse, en fonction de la priorité de l'incident

Les coûts liés à l'exploitation, à la maintenance et au support d'une solution numérique

Alors, combien coûte un SLA ? Comme souvent, la réponse est : « Ça dépend. »

Fondamentalement, tu as la certitude tout à fait légitime que nous restons à tes côtés et à ceux de ton produit une fois le développement initial terminé. En même temps, il n'est dans l'intérêt ni de notre part ni de celle de notre clientèle qu'une équipe de projet entière reste les bras croisés à attendre de devoir résoudre un problème dans un produit qui, espérons-le, ne se posera même pas. Il faut donc trouver un juste milieu entre « après le dernier sprint de développement, tout le monde s’en va » et « nous financons une équipe produit qui n'a rien à faire de la journée ». Ce juste milieu s’appelle la « disponibilité ».

La disponibilité est un élément essentiel (en termes de coûts) du SLA. Elle garantit que nous pouvons mobiliser une équipe de support capable de traiter toutes les demandes. Dans ce domaine, tout est une question de temps : si tous les cas de support doivent être traités dans des délais très courts, y compris le week-end en cas d'urgence, cela sera plus coûteux que s’il est acceptable de patienter un peu.

Le deuxième facteur de coût concerne le système lui-même. Les éléments suivants entrent en ligne de compte :

  • Quels sont les composants ? (Backend, API et interfaces, CMS, Frontends, etc.)

  • Quelle est l'ampleur de la solution ? Mots-clés : complexité, données, nombre d'utilisateurs

  • Quels sont les systèmes utilisés et quels coûts engendrent-ils ? Un serveur dans le cloud est presque toujours nécessaire, et celui-ci nécessite à son tour un service de surveillance. Autres services externes souvent utilisés et payants : services d'envoi d'e-mails, services d'authentification, prévention du spam et de la fraude, prestataires de services de paiement, etc.

Le troisième facteur, lié au deuxième, concerne les attentes envers notre service. Un exemple concret : dans la quasi-totalité de nos SLA pour les applications natives, il est prévu que nous testions l'application en été sur les versions bêta d'Android (Google) et d'iOS (Apple). Cela nous permet d'identifier les ajustements nécessaires avant la sortie des nouvelles générations de systèmes d'exploitation en automne. Si tu as la possibilité et l'envie de le faire toi-même : go for it ! Ton SLA sera plus avantageux, mais la responsabilité du bon fonctionnement de l'application après la mise à jour de l'OS te reviendra bien entendu.

Le support et les options constituent le dernier facteur : sur la base de notre expérience, nous te proposons une estimation de la charge de support à prévoir et incluons un contingent correspondant dans le contrat. Ce volume dépend fortement du produit ou du projet concerné.

En combinant ces quatre facteurs, on peut estimer à titre de règle générale un coût annuel d’environ 5 % à 15 % des frais de développement initiaux. Exemple concret : si le développement de ton application a coûté 100 000 francs, tu peux tabler sur des coûts de maintenance, d’exploitation et de support de l'ordre de 5 000 à 15 000 francs par an.

Ce que certains membres de notre clientèle trouvent également très pratique : nous réservons un certain budget dans le contrat pour des options. Cela offre la flexibilité nécessaire pour réaliser de manière pragmatique une petite modification – appelée « Change » dans le jargon informatique – sans devoir lancer un processus d'offre, de mandat ou d'achat. Nous nous adaptons entièrement à tes besoins et en discutons volontiers avec toi !

Apps with love peut-elle exploiter mon produit, même si je l'ai fait développer ailleurs ?

Oui et non. Pour pouvoir assumer une réelle responsabilité, nous devons comprendre un produit dans les moindres détails. C'est avec plaisir que nous ferons ta connaissance et celle de ton produit. Pour cela, une revision du code constitue généralement la première étape.

N'hésite pas à nous contacter si tu souhaites en savoir plus sur l'assistance et la gestion offertes par Apps with love, ou si nous pouvons t'aider !