Le piège du SLA : ce que vous signez dans votre contrat B2B engage votre architecture, pas votre commercial

Un client grand compte vous envoie son contrat-cadre. Page 14, annexe technique : « Disponibilité du service garantie à 99,9%, pénalités de 5% du montant annuel par tranche de 0,1% non respectée. » Votre commercial, pressé de signer le plus gros deal du trimestre, vous demande si « c’est bon ». Vous répondez oui, parce que dire non c’est risquer le deal. Vous venez de transformer une ligne juridique en dette technique.

Ce moment, presque tous les fondateurs B2B le vivent au passage vers les premiers gros comptes. Et la plupart le gèrent mal — non pas par incompétence, mais parce qu’ils traitent le SLA comme une clause contractuelle alors que c’est une décision d’ingénierie. La signature prend trente secondes. Tenir la promesse peut coûter des mois de travail et une part significative de votre runway.

Ce que 99,9% veut vraiment dire

Commençons par le seul chiffre qui compte, parce que personne ne le regarde au moment de signer. Un SLA à 99,9% autorise environ 8 heures et 45 minutes d’indisponibilité par an. Cela paraît confortable. Sauf que ces 8 heures incluent tout : vos déploiements ratés, une panne de votre fournisseur cloud, une migration de base de données qui dérape, un certificat SSL expiré un dimanche soir, un DDoS, un bug qui met l’API à genoux pendant que vous dormez.

Montez à 99,99% et vous tombez à 52 minutes par an. À ce niveau, un seul incident mal géré dans l’année fait exploser votre engagement. Vous n’avez plus le droit à l’erreur humaine, ce qui signifie concrètement que vous devez avoir automatisé le rollback, la détection, l’alerting et une partie de la remédiation. Ce n’est pas une question de volonté, c’est une question d’architecture et d’organisation.

Le piège, c’est que ces chiffres se ressemblent à l’écrit — un neuf de plus. Dans le réel, ils décrivent deux entreprises différentes. Le passage de 99,9% à 99,99% ne coûte pas 10% d’effort supplémentaire, il coûte souvent un ordre de grandeur : redondance multi-zone, bascule automatique, tests de charge réguliers, astreinte structurée. Pour une startup pre-seed ou seed avec trois développeurs, promettre 99,99% revient à hypothéquer plusieurs mois de roadmap produit.

Le SLA que vous signez suppose une architecture que vous n’avez probablement pas

Regardons ce qu’implique techniquement un vrai 99,9%. Cela suppose au minimum que votre application ne dépende pas d’un point unique de défaillance. Si votre base de données PostgreSQL tourne sur une seule instance sans réplica, une maintenance de votre hébergeur ou un simple redémarrage vous coûte votre SLA. Si vos déploiements provoquent une coupure — même de deux minutes — vous consommez votre budget d’indisponibilité à chaque mise en prod.

Beaucoup de startups early-stage vivent très bien avec une architecture mono-instance, un déploiement qui coupe brièvement le service, et pas d’astreinte le week-end. C’est parfaitement rationnel : tant que vos clients sont d’autres startups ou des PME tolérantes, personne ne compte les minutes. Le problème surgit à l’instant précis où vous signez un contrat qui, lui, les compte — et qui prévoit des pénalités.

Ce décalage est le cœur du piège. La décision commerciale (accepter la clause) et la réalité technique (l’architecture qui peut la tenir) sont prises par des personnes différentes, à des moments différents, sans se parler. Le commercial voit un chiffre acceptable. Le CTO découvre, trois mois plus tard, qu’il doit reconstruire la couche de déploiement pour éviter les coupures, mettre en place un réplica, installer de l’observabilité digne de ce nom, et organiser une astreinte — le tout pour un seul client.

Il y a aussi la question des dépendances externes, que presque personne ne modélise. Votre SLA à 99,9% s’appuie sur Stripe, sur votre fournisseur d’emails transactionnels, sur votre CDN, sur votre hébergeur. Si vous additionnez naïvement les disponibilités de quatre services critiques affichant chacun 99,9%, votre disponibilité théorique maximale tombe déjà sous 99,6%. Vous ne pouvez pas être plus fiable que le maillon le plus faible de votre chaîne — et vous venez de garantir mieux que ce que vos propres fournisseurs vous garantissent.

La pénalité n’est pas le vrai coût

On se concentre souvent sur les pénalités financières parce qu’elles sont écrites noir sur blanc. Mais elles sont rarement le problème principal. Le vrai coût d’un SLA mal calibré est diffus et se paie ailleurs.

Il se paie d’abord en coût d’opportunité sur la roadmap. Chaque heure passée à durcir l’infrastructure pour un client est une heure non passée à construire la feature qui vous fera signer les dix suivants. Une startup qui reconstruit son pipeline de déploiement zero-downtime pour honorer un seul contrat détourne son équipe de la validation produit — au moment où elle en a le plus besoin.

Il se paie ensuite en charge mentale et en rétention d’équipe. L’astreinte, quand elle n’est ni prévue ni rémunérée ni tournante, use les développeurs. Un fondateur technique qui devient de fait le seul répondant des incidents à 3 heures du matin crée un bus factor de un et un risque de burn-out — deux choses qu’un investisseur en série A regardera de près en due diligence.

Enfin, il se paie en crédibilité. Ne pas tenir un SLA affiché, c’est ouvrir une renégociation en position de faiblesse, donner au client un levier permanent, et abîmer une relation qu’on voulait justement solidifier avec ce contrat. Le SLA était censé rassurer ; mal tenu, il devient une épée de Damoclès.

Ce qu’il faut vraiment faire

La première chose est de découpler la signature de la promesse technique. Aucune clause de disponibilité ne devrait être acceptée sans qu’une personne comprenant l’architecture n’ait validé qu’elle est tenable — mesurée, pas espérée. Cela suppose d’avoir instrumenté votre disponibilité réelle avant même de négocier. Si vous ne mesurez pas votre uptime aujourd’hui, vous n’avez aucune base pour vous engager, et vous signez à l’aveugle. Un simple monitoring externe qui ping votre endpoint toutes les minutes vous donne déjà un chiffre honnête à opposer au commercial et au client.

Ensuite, négociez la définition avant de négocier le pourcentage. Le levier le plus puissant n’est pas le nombre de neuf, c’est le périmètre. Excluez explicitement les maintenances planifiées annoncées à l’avance. Définissez ce qui compte comme « indisponibilité » : une latence dégradée n’est pas une panne totale, une fonctionnalité secondaire en erreur ne devrait pas déclencher les pénalités du service entier. Fixez une fenêtre de mesure mensuelle plutôt qu’instantanée. Ces ajustements, invisibles pour un acheteur non technique, changent radicalement ce que vous devez construire — et sont bien plus faciles à obtenir que de faire baisser le pourcentage affiché, qui a une valeur symbolique pour le client.

Adaptez aussi votre posture au stade. En pre-seed et seed, tenez-vous à un SLA à 99,5% maximum (près de 44 heures d’indisponibilité annuelle de marge) et privilégiez les engagements « best effort » sans pénalités financières, en échange éventuellement d’un geste commercial. Un client qui accepte un service émergent accepte aussi, s’il est honnête, une fiabilité émergente. En seed avancé et approche de série A, quand vous visez plusieurs grands comptes, c’est le moment d’investir une bonne fois dans les fondations — déploiement sans coupure, réplica de base de données, observabilité, astreinte tournante — pour que 99,9% devienne un état de fait et non une promesse tendue.

Un principe sous-tend tout cela : construisez pour votre SLA interne, pas pour celui du contrat. Fixez-vous un objectif de disponibilité (un SLO) plus exigeant que ce que vous garantissez contractuellement. La marge entre les deux — votre budget d’erreur — est ce qui vous permet de déployer, d’expérimenter et de dormir. Une startup qui garantit 99,9% mais s’organise pour tenir 99,95% en interne se protège ; celle qui garantit exactement ce qu’elle atteint au mieux joue avec le feu à chaque incident.

En bref

Le SLA est l’un des rares endroits où une décision commerciale se traduit immédiatement en dette technique mesurable. La ligne signée en trente secondes définit l’architecture, l’organisation de l’astreinte et une partie de la roadmap des mois suivants. Ce n’est pas au commercial de la valider seul, ni au juriste — c’est une décision d’ingénierie déguisée en clause de contrat.

Avant de signer votre prochain contrat B2B, posez-vous la vraie question : mesurez-vous aujourd’hui votre disponibilité réelle, et savez-vous ce qu’il vous en coûterait, en euros de runway et en semaines de roadmap, de tenir chaque neuf que vous vous apprêtez à promettre ? Si la réponse est non, ce n’est pas le pourcentage qu’il faut négocier en premier — c’est votre capacité à le regarder en face.