Un budget annuel en trois lignes

Le déclencheur, pas la nature du travail. La maintenance technique, c'est ce que nous faisons à notre initiative, sans que vous ayez à le demander : veille, mises à jour, failles publiées, scans, outillage, bugs techniques. La maintenance client, c'est ce que vous nous demandez : améliorations, ajustements, adaptation à un tiers qui change, architecture, réunions de projet. La première est stable et se dimensionne sur ce que vous risquez, la seconde suit votre activité. Les confondre produit toujours le même effet : le budget de vos demandes absorbe l'entretien jusqu'à ce qu'il n'en reste rien.

Tout dépend de ce que dit la trace, une fois triée. Sentry remonte des erreurs, pas des verdicts : une exception dans notre code ou une tâche planifiée en échec est un bug technique, corrigé sur l'enveloppe de maintenance technique. Mais une API tierce qui a changé, un visiteur qui force une URL, une donnée supprimée dans Stripe ou HubSpot sans être synchronisée remontent aussi dans Sentry, et ce ne sont pas des bugs de votre logiciel : s'il y a du travail, c'est une adaptation, sur la maintenance client. Enfin, un comportement qui ne laisse aucune trace, un calcul qui ne donne pas ce que vous attendiez, un export auquel il manque une colonne : le logiciel fait ce que le ticket décrivait et que vous avez validé en recette. Ce n'est pas un bug, c'est une fonctionnalité qui n'était pas décrite, et elle relève de la maintenance client. C'est pour cela que la recette compte : elle fixe ce qui a été demandé.

L'enveloppe est un nombre de jours, dimensionné avec vous d'après vos réglages, et consommé à notre rythme : certaines périodes demandent plus de maintenance que d'autres. Ce qui sort du dimensionnement vous est remonté, et c'est vous qui décidez. Une campagne de publicité qui provoque un pic de trafic imprévu, une faille dont la correction impose de remplacer une bibliothèque entière : nous chiffrons le complément, vous ajustez l'enveloppe ou vous arbitrez. Rien ne se consomme en silence : la saisie des temps reste montrable à tout moment.

Oui. Un incident critique est pris en charge sous 4 heures ouvrées, un majeur sous 24, un mineur sous 72, du lundi au vendredi, de 9 h à 18 h, à condition d'avoir un engagement de maintenance technique. Ce qui varie d'un contrat à l'autre, ce sont les réglages : la fréquence du scan des CVE, celle du scan de sécurité et son seuil de correction, ce que nous faisons des alertes du monitoring. Un délai de prise en charge dit quand nous commençons à travailler sur un incident. Une faille publiée, elle, est corrigée sous 24 h ouvrées après détection : c'est la fréquence du scan qui fixe combien de temps elle peut rester ouverte.

Oui, c'est la politique « sur validation » : nous analysons chaque montée, nous vous la proposons avec son estimation, vous la validez et la financez. Nous continuons à travailler normalement tant que votre version reçoit des correctifs de sécurité de son éditeur. Une fois sa date de fin de vie passée, plus aucun correctif n'est publié : nous ne sommes plus en mesure de maintenir proprement le logiciel, et nous vous le disons. Repousser peut être une mesure temporaire, pour une entreprise en difficulté qui doit tenir encore quelques mois. Mais si une faille est découverte sur cette version, nous n'aurons rien à appliquer, et nous serons obligés de couper l'hébergement plutôt que de laisser en ligne une application que personne ne peut plus protéger.

Pas sur l'enveloppe annuelle. Une montée de Symfony 6 à 7 sur un socle suivi tient dans le flux ; la même montée sur une application laissée trois ans sans intervention est un chantier à cadrer et à estimer. Nous commençons alors par une offre ponctuelle de remise à niveau, qui ramène le socle dans une zone de support. C'est un préalable au contrat, pas une option : une enveloppe dimensionnée pour l'entretien d'un socle à jour ne peut pas absorber son rattrapage. Ce cas se produit à chaque fois qu'un budget de maintenance a été sous-dimensionné, ou n'a jamais existé.

C'est la troisième ligne du budget annuel, le Pack hébergement, et elle est distincte des deux autres parce qu'elle ne suit pas la même logique : elle se dimensionne sur la charge de votre application, quand la maintenance se dimensionne sur le niveau de suivi que vous voulez tenir. Elle regroupe l'hébergement sur Clever Cloud et les outils du projet : Sentry, UptimeRobot, Tipimail, GitLab CI et ses runners. La disponibilité de la plateforme, le système et les services managés relèvent de Clever Cloud. Si vos exigences portent sur cette couche, vous pouvez souscrire un contrat de support en direct avec eux.

Oui, et c'est plutôt souhaitable. Une application qui devient critique, une certification à obtenir, un client plus exigeant : la fréquence des scans, le suivi du monitoring ou la politique de version se révisent, et l'enveloppe avec. Nous préférons rouvrir la discussion une fois par an que tenir un réglage qui ne correspond plus à ce que vous vivez. Le mouvement inverse existe aussi, quand une application se stabilise et n'a plus de développement en cours.

Par des preuves produites par le travail lui-même, en plus du reporting mensuel de la TMA. Un rapport de scan repassé au vert avec l'état avant et après, l'état de support du socle à date, la chaîne d'intégration au vert avant chaque mise en production. Nous produisons ce dont vous avez l'usage, à la demande : une heure de démonstration en direct une fois par an vaut mieux qu'un rapport hebdomadaire que personne n'ouvre.