Pourquoi la maintenance est non négociable chez AINS

La plupart des agences vendent la maintenance comme une option qu’on ajoute après la mise en ligne, si on pense à la demander. Nous l’intégrons au contrat dès le premier jour, à chaque palier, parce qu’un site ne reste pas immobile après son lancement — il se dégrade silencieusement si rien ne le maintient activement.

Ce n’est pas un argument alarmiste. C’est ce qui arrive réellement à un logiciel qui parle à d’autres systèmes : un prestataire de paiement change le format de signature de ses webhooks, l’API d’une plateforme d’automatisation évolue sans ligne de changelog, un CMS publie une mise à jour majeure qui rend un plugin qui fonctionnait auparavant incompatible. Rien de tout ça n’est une erreur de quelqu’un. C’est simplement ce qui arrive à un code qui continue d’exister pendant que tout ce qui l’entoure continue d’évoluer. La panne n’est pas un bug dans le code que nous avons écrit — c’est un écart entre deux systèmes qui s’accordaient autrefois et ne s’accordent plus, et combler cet écart, c’est exactement à quoi sert un contrat de maintenance.

Ce qui casse même quand personne n’a rien fait de mal

Chaque forfait mensuel que nous gérons garde une fenêtre de correctif ouverte pour une liste courte et précise de catégories de pannes — pas une vague promesse de « faire en sorte que ça tourne ». Concrètement : l’épuisement des crédits d’API d’un CRM, un format de webhook de paiement qui change, le contrat d’une API de téléphonie qui évolue sous une intégration, une mise à jour majeure d’un CMS qui rend un plugin fonctionnel soudain incompatible. Ce ne sont pas des hypothèses. Ce sont les catégories que notre propre supervision a réellement interceptées, plus d’une fois, sur les stacks d’automatisation que nous faisons tourner aujourd’hui.

Ce que surveille réellement l’infrastructure de supervision

Chaque site ou système sous contrat actif est relié à une supervision qui surveille quatre choses : les erreurs, les ralentissements, les régressions visuelles, et les vulnérabilités des dépendances. La plupart du temps, le correctif est déjà en ligne avant qu’un client n’ait rien remarqué — la supervision nous prévient avant d’avoir jamais besoin de vous prévenir.

Ce qu’un client remarque réellement

Quand elle est bien faite, la maintenance est ennuyeuse du point de vue du client — rien ne casse, rien ne change de façon inattendue, le rapport mensuel dit la même chose rassurante que le mois précédent. C’est tout l’intérêt. L’alternative n’est pas une panne spectaculaire ; c’est une accumulation lente de petites défaillances passées inaperçues, qui finissent par faire découvrir au client, par lui-même, que quelque chose était cassé depuis des semaines.

Ce qui est inclus, pas vendu en option

La ligne maintenance de chaque palier couvre le même terrain : données clients hébergées dans l’UE, sauvegardes quotidiennes chiffrées, correctifs de sécurité, supervision de disponibilité avec alertes, un rapport de santé mensuel, et un export des données sur demande à tout moment — jamais retenu en otage. Chaque contrat Run démarre aussi par une garantie d’intégration de 90 jours avant de basculer sur un forfait mensuel classique, si bien que les aspérités du premier trimestre sont à notre charge, pas à celle du client.

Pourquoi il nous coûte moins cher de continuer à surveiller que d’attendre un ticket

Réparer un système que nous connaissons déjà — son schéma, ses automatisations, son graphe de dépendances — prend quelques minutes quand on l’intercepte tôt. Réapprendre ce même système à partir d’un ticket de support paniqué six mois après notre dernière intervention prend des heures, parfois une journée entière, et ça se passe dans de moins bonnes conditions : un client est déjà agacé, et quelque chose en aval a peut-être silencieusement dysfonctionné pendant des semaines. La maintenance n’est pas de la générosité. C’est la façon la moins chère de faire tourner l’activité, pour nous comme pour le client. Ça veut aussi dire qu’une conversation de support démarre par « voici ce qui a changé et voici le correctif », pas par « laissez-moi d’abord comprendre à quoi ce système était censé servir ».

Ce que ça donne à l’échelle

FORMAFORCE fait tourner plus de 85 workflows n8n en production, synchronisant leads, appels et facturation dans un CRM qui alimente un tableau de bord en direct consulté chaque jour par 6 vendeurs. Une stack de cette taille ne tombe pas en panne bruyamment — elle échoue sous forme de quelques fiches en double ou d’un webhook silencieusement perdu, le genre de chose que personne ne remarque avant que les chiffres du tableau de bord ne correspondent plus à la réalité. Surveiller cette stack dans la durée est ce qui nous a permis de trouver et de durcir un schéma de clé d’idempotence après huit incidents de duplication distincts — le genre de correctif qui n’est possible que parce que quelqu’un regardait déjà, pas parce qu’un client a ouvert un ticket. L’étude de cas complète est ici : /fr/work/paris-sales-ops-automation.

Le pack Run de notre page services détaille exactement ce qui est inclus à chaque niveau, SLA publié compris : /fr/services#run.