Les développements applicatifs d’un projet vendu au forfait incluent en général une garantie plus ou moins longue selon les projets et les marchés.

Chez Solstys nous proposons une garantie de 3 mois par défaut qui peut être étendue par la suite via un contrat de maintenance corrective et / ou évolutive sur-mesure en fonction des besoins, de la criticité et de la dimension du projet.

La garantie couvre la correction des éventuels bugs résiduels, qui n’auraient pas été détectés lors de la phase de recette (voir article « la recette c’est quoi ?« ) ainsi que le support technique aux administrateurs de la solution (par téléphone, email, visio ou prise en main à distance).

Tout dysfonctionnement ou bug peut être remonté par un système de tickets en ligne (nous utilisons l’outil Redmine qui est rapide et simple), nos clients peuvent ainsi, via leur compte et des notifications, suivre l’évolution et la résolution des tickets qu’ils ont remontés.

Quand des corrections sont apportées, les équipes de développement mettent à jour le package / les sources de l’application sur le serveur de développement ou la machine qui compile l’application. Les corrections sont ensuite répercutées après tests sur le serveur de production (cas des applications web ou Progressive Web Apps) ou proposées à la publication sur les stores (cas des applications mobiles diffusées dans les stores).

La maintenance corrective est – pour schématiser – une extension de la garantie initiale quand celle-ci est expirée. On peut considérer que c’est comme une police d’assurance pour votre logiciel ou votre application : vous n’allez pas forcément la solliciter en cours d’année (nous faisons en sorte de limiter les sources de bugs dès la conception en utilisant toutes les bonnes pratiques du développement) mais vous serez bien content d’en disposer en cas de problème !

Elle inclut également et c’est très important :

  • le maintien des compétences autour des technologies utilisées lors du développement
  • le maintien de la connaissance métier acquise, du contexte, de l’historique, des tenants et aboutissants spécifiques au projet
  • la capacité technique à intervenir, à corriger des bugs, à faire évoluer l’application et l’ensemble de ses composants
  • le recrutement et le transfert de compétences à un nouveau développeur en cas de turn-over dans nos équipes

En fonction des projets, cette maintenance peut être forfaitaire et calculée selon plusieurs méthodes (par exemple coût annuel correspondant à 10% à 15% de la charge de développement initiale) ou prendre une autre forme (par exemple nous pouvons côté Solstys provisionner un certain nombre de jours ou d’heures de développement par mois).

Au niveau du contrat, il est possible de mixer et d’inclure en plus du correctif un certain nombre de jours pouvant être utilisés à la fois pour des corrections et / ou des demandes de modifications / évolutions.

Si nos clients souhaitent un interlocuteur technique unique, nous pouvons également inclure au contrat la partie hébergement des applications (nous gèrerons alors avec les éventuels prestataires-tiers la résolution d’incidents relatifs à cette partie).

La garantie ne couvre en général pas le support technique aux utilisateurs finaux des solutions développées. Les administrateurs ou les équipes internes chez nos clients peuvent eux-mêmes assurer le support technique à leurs utilisateurs via différents moyens : FAQ (questions fréquemment posées), manuel / guide d’utilisation en ligne, captures vidéos, outil de chat support intégré au logiciel (cela nécessite bien sûr d’avoir une ressource qui prend en charge les demandes internes).

Le paragraphe suivant concerne surtout les applications mobiles pour lesquelles il est possible d’inclure dans le contrat de maintenance les évolutions « forcées » rendues nécessaires par l’évolution de l’écosystème technologique ou des règles dans l’environnement de diffusion des applications (stores Apple et Google).

Par exemple si Facebook change en cours de route sa méthode de connexion ou de sécurisation des échanges de données, cela va nécessiter une montée en version de tous les composants de l’application qui utilise l’API de Facebook (voir l’article « les APIs c’est quoi ?« ).

Autre exemple : si Apple impose, à partir d’une date donnée, une évolution technique ou fonctionnelle, toutes les applications (les nouvelles ainsi que celles déjà dans les stores) présentant une nouvelle version à la publication devront obligatoirement inclure cette fonctionnalité pour avoir une chance d’être validées ou publiées.

Inclure la prise en charge de ces évolutions forcées par le prestataire dans un contrat de maintenance représente donc en général un coût supplémentaire.

Le contrat peut alors prévoir un nombre de jours provisionnés pour tous les types d’intervention possible :

  • les corrections
  • les évolutions souhaitées par le client
  • les évolutions rendues obligatoires sous peine d’obsolescence technique ou de « disqualification » par les stores.