L’engagement impossible · Fiche de décision 01

Comment répondre à une exigence de disponibilité de 100 %

Situation illustrative · Pas un cas client
La question de l’acheteur

Pouvez-vous garantir une disponibilité du service de 100 % ?

Ne transformez pas un objectif de fiabilité en garantie d'absence totale d'interruption. Énoncez l'engagement approuvé pour le périmètre réellement demandé par l'acheteur ; si les 100 % sont obligatoires et non négociables, une réponse assortie de réserves ne rend pas l'offre conforme.

Une réponse à adapter

Nous ne pouvons pas garantir une disponibilité ininterrompue en toutes circonstances. Pour [service, déploiement et fonctions couverts], nous proposons [engagement de disponibilité approuvé], mesuré sur [période de mesure] selon [méthode de mesure convenue], sous réserve de [exclusions précises prévues dans les conditions proposées]. Les mesures applicables en cas de manquement sont [mesures approuvées et référence contractuelle]. Notre proposition comprend [mesures de résilience et de reprise vérifiées], dont le périmètre et les résultats de tests figurent dans [références des preuves]. Les engagements de reprise sont énoncés séparément dans [conditions de reprise approuvées] ; ils ne constituent pas une promesse d'absence d'interruption. Merci de confirmer, par [canal autorisé pour les demandes de clarification], si cet engagement défini est acceptable pour l'exigence [ID], ou si une garantie de 100 % sans réserve conditionne la recevabilité de l'offre.

Remplacez chaque champ entre crochets par un fait vérifié. Supprimez toute phrase facultative que vous ne pouvez pas justifier. Ne soumettez pas cette formulation telle quelle.

La fiche d'engagement de disponibilité

Avant d'inscrire un pourcentage dans la réponse, rapprochez ces cinq éléments. Une divergence appelle une validation technique et commerciale, pas une reformulation destinée à la masquer.

Qu'est-ce qui constitue une défaillance ?
Définissez l'opération utilisateur en échec, le seuil d'interruption et le point de mesure. Une page d'état de l'infrastructure ne prouve pas, à elle seule, la réussite des opérations de l'acheteur de bout en bout.
Sur quelle période ?
Indiquez la période et le fuseau horaire. Distinguez la disponibilité calculée sur le temps du taux de requêtes réussies : un même pourcentage peut recouvrir des expériences utilisateur sensiblement différentes.
Quelles exclusions ?
Identifiez explicitement la maintenance, les défaillances des dépendances et les responsabilités du client. Vérifiez que l'acheteur autorise ces exclusions au lieu de recopier votre contrat standard sans adaptation.
Que pouvez-vous démontrer ?
Rapprochez l'architecture déployée, la couverture de supervision et les tests de reprise de cette opportunité. Présentez une configuration future promise comme une proposition, pas comme une configuration déjà opérationnelle.
Que se passe-t-il en cas de manquement ?
Consignez la conséquence négociée et la procédure de réclamation. Avoirs de service, droits de résiliation et exposition financière exigent une approbation ; le rédacteur de l'offre ne les choisit pas.

Les conditions à vérifier

Distinguez une promesse de disponibilité absolue d'un engagement de service mesurable. Définissez le périmètre, les preuves et les réserves avant de répondre.

  • Définir le service que l'acheteur utilisera réellement

    Précisez le déploiement de production, les opérations couvertes, les horaires de service et le périmètre de supervision. Un serveur sain ne signifie pas nécessairement une application utilisable. Déterminez si l'authentification, les intégrations, les traitements en arrière-plan et la connectivité gérée par l'acheteur sont inclus. Ne réduisez pas implicitement l'exigence : toute exclusion importante doit apparaître dans la réponse et les conditions proposées.

  • Distinguer quatre engagements différents

    Un objectif de conception, une disponibilité historique mesurée, un SLA contractuel et un objectif de reprise répondent à des questions différentes. Les résultats historiques décrivent une période ; un SLA définit une obligation approuvée et les mesures applicables en cas de manquement. Les objectifs de délai de reprise et de point de reprise concernent le rétablissement et la perte de données. Aucun ne remplace automatiquement la disponibilité continue.

  • Le SLA d'un prestataire n'est pas celui de votre application

    L'engagement d'un fournisseur cloud concerne son service défini et l'architecture qui y donne droit, pas automatiquement l'ensemble du parcours de votre client. Le Compute SLA d'AWS distingue par exemple engagements régionaux et engagements par instance, avec exclusions et règles d'avoirs. Utilisez-le pour illustrer une vérification du périmètre, pas pour prouver la fiabilité de votre produit.

Les justificatifs à réunir

  • Conditions de service approuvées

    Obtenez la version exacte du SLA, la définition de la mesure, les exclusions, les mesures de réparation et l'ordre de priorité des documents. Consignez les approbations technique et juridique des écarts à l'offre standard. Ne renseignez pas le pourcentage avant de disposer de ces éléments.

  • Preuves d'exploitation comparables

    Demandez les données de supervision correspondant au périmètre proposé, à la période de référence et aux lacunes connues. Distinguez performance observée et performance garantie. Incluez les incidents pertinents plutôt que de retenir uniquement le mois le plus favorable.

  • Dispositifs de continuité testés

    Obtenez le schéma de déploiement actuel, l'inventaire des dépendances et les résultats datés des tests de reprise ou de bascule. Confirmez ce qui a été testé, les défaillances simulées et les éventuelles actions attendues de l'acheteur.

La décision à faire valider

Responsables de la validation
L'équipe technique ou le responsable du service confirme la faisabilité ; le juridique et l'autorité commerciale approuvent l'obligation. Le responsable d'offres consigne la décision de recevabilité et maintient les réserves.
Poursuivre
Poursuivez avec une réponse assortie de réserves uniquement si l'engagement proposé est étayé, approuvé et autorisé par les instructions de l'acheteur ou une clarification faisant autorité.
Ne pas poursuivre
Ne répondez pas Oui si cela revient à accepter une garantie d'absence d'interruption non étayée. Si l'exigence est obligatoire et que l'acheteur refuse les alternatives, maintenez l'écart et faites arbitrer la décision de soumission.
Faire arbitrer
Demandez à l'acheteur de distinguer objectif de disponibilité, engagement contractuel et exigence de continuité. Respectez la procédure autorisée pour les questions ; ne vous fondez pas sur une assurance informelle obtenue en dehors de celle-ci.

Conserver la décision dans les fichiers à déposer

Avant d'autoriser le dépôt de l'offre, vérifiez que la réponse finale conserve le périmètre de service, le pourcentage et les exclusions approuvés, et cite la bonne révision du SLA. REQVERA est une couche de contrôle final des exigences, réponses, preuves approuvées et fichiers à déposer — pas un garant de disponibilité ni un outil de négociation des dérogations.

Voir le parcours réel de contrôle final

Périmètre et sources de référence

Question d'acheteur illustrative, pas un cas client rapporté. Pratiques générales de réponse concernant les engagements de disponibilité ; aucun SLA ni aucune capacité de REQVERA n'est affirmé. La portée juridique du contrat et les conditions obligatoires de la consultation exigent la revue juridique et achats appropriée.

  • Google SRE: Service Level Objectives

    Référence technique primaire distinguant indicateurs, objectifs et accords, et mettant en garde contre les objectifs de disponibilité absolue. Ce n'est pas le SLA actuel d'un produit Google.

  • Amazon Compute Service Level Agreement

    Exemple propre à ce fournisseur d'engagements dépendant de l'architecture, de définitions, d'exclusions et de mesures de réparation. Il n'établit pas le SLA du fournisseur qui répond.