Le pourcentage affiché en gros sur la page marketing n'est jamais le problème. Le problème, c'est la définition du mot "downtime" écrite en petit dans l'annexe du contrat.

La maintenance planifiée est souvent exclue du calcul. Un fournisseur peut annoncer 99,9 % et retirer de son calcul toute fenêtre de maintenance annoncée 24h à l'avance. Résultat : il peut couper le service quatre heures par mois, prévenir la veille, et prétendre respecter son SLA à la lettre. Vérifie toujours si la maintenance planifiée compte dans le calcul ou si elle est retranchée du temps total.

La définition exacte de "indisponible" varie. Est-ce que ton API est considérée en panne si elle répond en 15 secondes au lieu de 200 millisecondes ? Certains contrats ne comptent le downtime que si le service renvoie une erreur HTTP 5xx pendant plus de 5 minutes consécutives. Une dégradation lente qui rend ton produit inutilisable sans jamais franchir ce seuil ne déclenche aucun crédit, alors que tes utilisateurs, eux, subissent la panne.

Les crédits de service sont dérisoires face aux pertes réelles. Le schéma classique : 10 % de crédit sur la facture mensuelle si l'uptime tombe sous 99,9 %, 25 % sous 99 %, 50 % sous 95 %. Sur un abonnement à 49 $/mois, un crédit de 10 % représente 4,90 $. Si cette panne a empêché 3 000 personnes de scanner un QR code d'accès à un événement payant, la perte réelle se chiffre en milliers de dollars. Le contrat protège la marge du fournisseur, pas ton business.

Les exclusions "force majeure" sont parfois écrites large. Certains contrats excluent toute panne liée à un "problème réseau tiers", ce qui peut couvrir à peu près n'importe quel incident de DNS, de CDN ou de cloud provider en amont, même si le fournisseur avait le choix de son infrastructure.

Avant de signer, je recommande de demander le texte exact de la clause SLA, pas le résumé marketing. Si le fournisseur hésite à le montrer avant la signature, c'est un signal.

Grille pour comparer les fournisseurs

Le pourcentage seul ne suffit pas. Voici la grille que j'utilise pour évaluer un fournisseur d'API QR dynamique avant de recommander un contrat à un client.

Historique de statut public. Un fournisseur sérieux publie une page de statut avec l'historique des incidents des 12 derniers mois, pas juste le mois en cours. Si la page de statut n'existe pas ou n'affiche que "tout va bien" en permanence sans historique consultable, méfiance.

Transparence sur les incidents passés. Cherche des post-mortems publics : quand une panne survient, le fournisseur explique-t-il la cause, la durée réelle, et les mesures prises pour éviter la répétition ? L'absence totale de communication sur un incident majeur en dit long sur la culture de l'entreprise.

Redondance d'infrastructure réelle. Demande si l'API tourne sur une seule région cloud ou si elle bascule automatiquement vers une région secondaire en cas de panne. Un SLA élevé sans redondance géographique repose entièrement sur la fiabilité d'un seul datacenter.

Temps de bascule réel, pas théorique. Un failover automatique qui prend 20 minutes à se déclencher grignote une bonne partie du budget de 43 minutes mensuelles. Demande des chiffres précis, pas des promesses vagues.

Cache-Control sur les redirections. Ce point est technique mais concret : si le fournisseur met en cache les redirections au niveau CDN, changer la destination d'un QR code peut prendre des heures à se propager, même si l'API elle-même est disponible à 99,9 %. Ton QR est "up" selon le SLA, mais il pointe vers la mauvaise page. Chez QR Code Agency, chaque redirection impose un header Cache-Control: no-store, donc un changement de destination est effectif immédiatement, pas après propagation de cache.

Le SLA Enterprise vaut-il vraiment plus que le SLA standard ? Sur l'offre Enterprise de QR Code Agency, on s'engage sur 99,95 % avec failover régional, ce qui correspond à environ 22 minutes d'indisponibilité tolérée par mois au lieu de 44. C'est un engagement Enterprise, pas une promesse générique appliquée à tous les plans, et je pense que c'est la bonne façon de faire : ne pas vendre le même SLA à un usage gratuit et à un usage critique en production.

Si tu génères des milliers de QR codes par lot pour une campagne, la fiabilité de l'API pendant l'appel batch compte aussi. J'ai détaillé ce sujet dans l'article sur la génération QR en masse avec CSV vers API : un timeout au milieu d'un batch de 5 000 codes pose un problème différent d'une simple panne de redirection.

Ce que je vérifie avant de signer

Trois éléments concrets, dans l'ordre où je les vérifie.

D'abord, le texte exact de la clause de crédit de service. Pas le pourcentage marketing, le montant réel en dollars ou en pourcentage de facture que tu reçois si le seuil est franchi. Si ce montant ne couvre même pas une fraction de ta perte potentielle, négocie ou cherche ailleurs.

Ensuite, la fenêtre de mesure. Un SLA calculé sur 12 mois glissants masque une panne catastrophique de deux jours en la diluant sur l'année. Un SLA calculé mois par mois expose chaque incident individuellement, ce qui est plus honnête et plus facile à vérifier.

Enfin, l'historique public des incidents. Une entreprise qui documente ses pannes avec transparence inspire plus confiance qu'une qui affiche un chiffre lisse sans jamais expliquer ce qui s'est passé derrière.

Je ne pense pas qu'un SLA à 99,9 % soit un mauvais chiffre en soi. C'est un point de départ correct pour la majorité des usages. Mon problème, c'est de le vendre comme une garantie absolue sans expliquer ce qu'il exclut. Un développeur qui choisit une API code qr dynamique pour son produit mérite de savoir exactement ce qui se passe le jour où le service tombe, pas seulement le pourcentage affiché sur la page tarifs.

La prochaine fois que tu compares des offres, ignore le badge "99,9 % uptime" en gros caractères et va chercher le PDF du contrat. Cherche le mot "downtime" et lis sa définition trois fois. C'est la seule action qui protège réellement ton business, bien avant de discuter du prix ou des fonctionnalités.

---

A lire aussi

• SDK Natif, JS ou API REST : le Vrai Comparatif QR
• API QR Dynamique : le Vrai Coût Selon vos Volumes
• Applications mobiles québécoises populaires utilisant les codes QR