---
title: "Répondre à une question de scalabilité avec des mesures"
description: "Transformez la demande en charge reproductible, puis exposez la zone testée, la saturation et l’extension sans révéler la topologie sensible."
canonical: "https://zephior.com/fr/insights/answer-an-rfp-scalability-question"
last-updated: 2026-09-05
---

# Répondre à une question de scalabilité avec des mesures

> Transformez la demande en charge reproductible, puis exposez la zone testée, la saturation et l’extension sans révéler la topologie sensible.

Par [Tony Kim](https://zephior.com/fr/authors/tony-kim). Publié le 2026-09-05; mis à jour le 2026-09-05. 20 min de lecture.

## Définition

Un dossier de preuve de mise à l’échelle relie une demande précise de l’acheteur à une charge définie et à des résultats que l’on peut reproduire. Il conserve les opérations utiles, la courbe d’arrivée, la concurrence, les données, le périmètre, la version testée, la proximité de l’environnement, les critères, les paliers, les résultats, la première limite, la zone d’exploitation, la réaction à la saturation, le délai d’ajout de capacité, les alertes, le déclencheur d’extension, les dépendances, le coût et les approbations. Il distingue mesure, calcul, prévision, conception proposée et inconnue. La réponse publique en reprend les faits utiles sans publier les adresses, seuils défensifs ni détails d’accès du système.

## Problème

Le Syndicat de mobilité fictif de Val d’Orme veut ouvrir un portail d’indemnisation après une interruption majeure du réseau. Son RFP demande la prise en charge de 65 000 voyageurs pendant les vingt premières minutes, avec dépôt de justificatifs, contrôle du titre de transport, calcul du remboursement et information sur le statut. Le brouillon promet une plateforme élastique qui absorbe toute pointe. Le test cité a envoyé des consultations de page pendant six minutes sur une base vide. Il n’a pas reproduit les reçus photographiés, les appels vers le valideur de titres, les écritures financières ni le traitement des dossiers suspects. Il compte chaque nouvelle tentative comme du débit et ne mesure ni les dossiers terminés ni le délai de rattrapage. L’affirmation est large; la preuve porte sur un autre travail.

## Point de vue

La capacité se prouve avec une demande située dans le temps et un résultat métier. Décrivez ce que font les voyageurs, à quel rythme, avec quelles pièces, sur quels réseaux et avec quels services externes. Reproduisez la version offerte, une population de données crédible, les échecs attendus et le travail différé. Suivez les dossiers correctement terminés, la distribution des délais, les refus, les erreurs, l’âge des files et la pression des ressources. La réponse donne ensuite une zone testée, le premier facteur limitant, la conduite au-delà de cette zone et la décision nécessaire pour augmenter la capacité.

## Soixante-cinq mille voyageurs ne créent pas tous la même charge

Relevez chaque volume dans le règlement, le cahier technique, les parcours, les interfaces, les délais de remboursement, les données de reprise et la méthode de notation. Le chiffre de 65 000 voyageurs sur vingt minutes n’indique pas combien ouvrent une page, démarrent un formulaire, déposent trois photos ou reprennent une demande. Il ne dit pas non plus si le pic arrive en une minute après une notification ou progresse pendant toute la fenêtre. Le test doit porter sur ces différences.

Définissez une unité métier par parcours. Pour une indemnisation, la réussite peut exiger un dossier enregistré, un titre contrôlé, un montant calculé et un identifiant consultable. Un accusé de réception HTTP ne suffit pas si l’analyse d’image échoue ensuite. Donnez à chaque opération un taux d’arrivée, une durée active, une proportion, une plage de pièce jointe, un état de données, des appels externes et une fin observable.

Le traitement invisible compte aussi. Analyse des justificatifs, contrôle de doublons, rapprochement avec les validations, production d’écritures, notification et files d’examen manuel peuvent continuer après la réponse à l’écran. Placez-les sur la même chronologie. Lorsqu’un volume ou une répartition manque, conservez une fourchette et ses branches de décision. Une hypothèse interne approuvée ne devient pas un fait fourni par Val d’Orme.

**Profil initial de la pointe de Val d’Orme**

| Opération | Dimension de charge | Critère de fin utile |
| --- | --- | --- |
| Vérifier l’éligibilité | Requêtes par minute, période et service de validation | Titre et trajet reconnus avec une décision enregistrée |
| Déposer la demande | Sessions concurrentes, champs, images et abandons | Dossier durable, pièces liées et référence restituée |
| Calculer le remboursement | Règles, historiques, contrôles et écritures | Montant vérifié ou orientation motivée vers examen |
| Consulter le statut | Lectures répétées après le dépôt et notifications | État courant cohérent avec le traitement de fond |

## Une pointe soudaine et un plateau de vingt minutes sont deux essais

Distinguez le taux d’arrivée, le nombre d’opérations simultanées, les sessions inactives et les connexions ouvertes. Une personne peut attendre entre deux étapes alors que le serveur ne travaille pas pour elle; à l’inverse, une seule demande peut lancer plusieurs opérations différées. Conservez le lien entre ces unités, sans les convertir avec un coefficient implicite.

Préparez une rampe ordinaire, une ouverture brutale, une pointe tenue et une période de rattrapage. Ajoutez un essai prolongé si les écritures, fichiers, files ou connexions peuvent s’accumuler. Les nouvelles tentatives méritent leur propre modèle. Un client qui réessaie sans attente augmente la demande au moment même où le service manque de capacité. Le scénario doit reproduire la règle proposée aux utilisateurs et aux intégrations.

Répartissez les origines et conditions de réseau lorsque cela change le parcours. Des téléphones sur réseau mobile envoient des images lentement, interrompent un transfert et reprennent parfois le dossier. Le test peut émuler ces propriétés sans recueillir de données personnelles réelles. Expliquez ce qui a été reproduit et ce qui reste une limite. Une série de clients rapides dans un seul centre ne prouve pas le comportement de toutes les situations prévues.

## La version, les données et les dépendances bornent chaque résultat

Figez la version du logiciel, les fonctions actives, la classe de configuration, le schéma de données et les contrats des interfaces. Notez la relation entre l’environnement de test et le service proposé: catégorie de capacité, région, réseau, stockage, état des caches, journalisation et politique d’ajout de ressources. Le dossier interne garde le détail nécessaire à la reproduction. La réponse externe utilise des catégories et des différences matérielles, pas une carte exploitable du système.

Constituez une population qui reproduit les propriétés influentes: années de validations, relations entre cartes et voyageurs, dossiers précédents, distributions de montants, images variées, droits d’accès et cas rejetés. Des données synthétiques autorisées suffisent si leurs relations et distributions sont contrôlées. Une copie de production n’est ni nécessaire ni automatiquement permise.

Classez enfin la portée de chaque preuve. Un résultat observé décrit exactement son essai. Un calcul applique une formule documentée. Une prévision propose une demande future. Un plan d’extension décrit une action encore à exécuter. Une dépendance acheteur ou fournisseur conditionne la conclusion. ISO/IEC 25030 aide à organiser les exigences de qualité et ISO/IEC 25040 leur évaluation; aucune de ces normes ne fournit à Val d’Orme un volume garanti prêt à copier.

**États de preuve avant rédaction**

| État | Contenu exigé | Usage autorisé |
| --- | --- | --- |
| Mesuré | Objet, version, charge, environnement, résultat, date et traces | Rapporter le domaine testé et ses conditions |
| Calculé | Entrées, formule, limites de proportion et contrôle | Présenter une déduction bornée, jamais une mesure directe |
| Prévu | Source de demande, scénarios, incertitude et date de décision | Expliquer la base de planification et sa vérification |
| Extension proposée | Action, responsable, délai, coût, dépendances et recette | Promettre seulement après autorisation de l’offre |

## Le débit s’arrête au résultat métier, pas à la première réponse

Comptez les dossiers qui atteignent la fin définie. Rapprochez dépôts reçus, fichiers conservés, contrôles terminés, montants calculés, cas orientés et statuts publiés. Séparez rejet fonctionnel, erreur technique, expiration, abandon, reprise et doublon. Une augmentation des requêtes pendant une difficulté peut signaler les relances des clients plutôt qu’une capacité supérieure.

Mesurez plusieurs points de la distribution des délais pour chaque parcours critique. Un percentile porte toujours sur une population déterminée et une règle de traitement des erreurs. Ajoutez exactitude du calcul, cohérence du statut et intégrité des pièces. Un système rapide qui perd une photographie ou duplique une écriture financière ne remplit pas le besoin, même si ses réponses techniques arrivent à temps.

Observez le volume et l’ancienneté des files. Le nombre peut cesser de croître alors que les dossiers les plus anciens stagnent. Mesurez l’âge maximal, le taux d’entrée, le taux de sortie et la durée de vidage après la pointe. La métrique OpenTelemetry de durée des requêtes HTTP serveur est stable; celle des requêtes actives reste facultative et porte le statut Development. Ces mesures décrivent l’activité HTTP. Le dossier d’offre doit les compléter par les étapes métier et les contrôles de données.

## Le premier signe de saturation peut être une file qui vieillit

Augmentez la charge par paliers et maintenez chaque niveau assez longtemps pour observer le travail différé. Alignez demande, achèvements, percentiles, erreurs, files, dépendances et ressources sur une même échelle de temps. Le point de déformation apparaît lorsque la demande ajoutée ne produit plus un gain comparable de dossiers utiles, que les fins de distribution s’allongent ou qu’un stock de travail persiste.

Placez la zone offerte sous l’instabilité observée. La marge tient compte de l’incertitude de prévision, des changements ordinaires, d’un fournisseur plus lent, d’une répartition inégale, du délai d’ajout de capacité et des périodes de maintenance. Aucun pourcentage universel ne convient. La décision doit expliquer ses facteurs et son propriétaire. Si le test s’arrête avant toute déformation, son dernier palier est une capacité au moins démontrée, pas une capacité maximale.

Poussez ensuite, dans un cadre autorisé, au-delà de la zone. Vérifiez refus explicites, limitation, priorité, maintien de l’intégrité et récupération. Une fonction allégée reste acceptable seulement si le besoin essentiel demeure satisfait et si l’acheteur l’accepte. Les travaux Google SRE sur les défaillances en cascade montrent pourquoi il faut tester surcharge, rejet et relances. Ils ne remplacent pas la mesure propre au portail de Val d’Orme.

**Lecture d’un essai progressif à Val d’Orme**

| Palier | Constat conservé | Conclusion permise |
| --- | --- | --- |
| Charge courante | Dossiers achevés, délais et files restent alignés sur la demande | Comportement stable pour ce profil et cette version |
| Pointe prévue | L’ajout de capacité ramène les files dans la plage retenue | Réaction d’extension observée dans les conditions citées |
| Au-delà de la pointe | Le contrôle des justificatifs ralentit avant le dépôt en ligne | Le traitement différé est la première limite mesurée |
| Retour | Les dossiers acceptés sont rattrapés sans perte ni écriture double | Récupération démontrée pour cet épisode |

## Une ressource créée devient utile quand elle prend du travail

Décomposez le changement de capacité. Le signal est observé pendant une fenêtre, une décision demande des ressources, celles-ci sont fournies, préparées, reliées au trafic ou à la file, puis produisent du travail utile. Chronométrez chaque étape. Un traitement lancé peut encore charger son état, attendre une partition ou ne recevoir aucun dossier. Mesurez aussi la réduction après la pointe, car un retrait trop rapide peut interrompre du travail accepté.

Identifiez les éléments qui ne suivent pas le même facteur. Base partagée, ordre strict, fournisseur de paiement, quota de validation, licence, stockage ou circulation des données peuvent rester fixes. Le guide Azure sur la mise à l’échelle mesure le gain de débit par rapport aux ressources ajoutées et rappelle le rôle des points de synchronisation. Employez cette relation dans son domaine. Ne promettez pas qu’un doublement de ressources double chaque parcours.

La demande au-delà de la zone actuelle reçoit une action nommée. Préallocation, hausse de quota, nouvelle partition de données, capacité dans une autre région, contrat fournisseur ou évolution du produit peuvent être nécessaires. Conservez déclencheur, délai, coût, dépendance, test de recette et personne habilitée. Une évolution non livrée reste un projet proposé et ne gonfle pas la capacité actuelle.

## La preuve interne doit être plus détaillée que la réponse publiée

Archivez plan, profil de charge, recette de données, version, description de l’environnement, heures, journaux du générateur, séries de mesures, calculs, écarts et incidents. Notez le nombre de répétitions et leur variation. La RFC 8239 traite des benchmarks de réseau de centre de données; son exigence de répétabilité et de compte rendu offre un exemple circonscrit. Ses seuils propres au réseau ne deviennent pas des règles générales pour ce portail.

Chaque nombre public renvoie à un instantané de preuve. Une autre personne doit pouvoir recalculer le résultat avec les succès, échecs et exclusions. Conservez les intervalles retirés et leur raison. Si le générateur a limité un palier, rejouez ce palier ou réduisez la conclusion. Choisir après coup l’essai le plus favorable détruit la représentativité, même si aucune donnée n’a été falsifiée.

Fixez les événements de réouverture: nouvelle version, changement de schéma ou de parcours, profil de fichier différent, classe d’environnement, région, dépendance, quota, politique d’extension ou perte de mesure. Une révision du besoin de l’acheteur déclenche la même vérification. Les éléments sensibles restent dans le dossier à accès contrôlé; le texte externe conserve méthode, portée, résultat et limites suffisants pour une évaluation loyale.

## Répondez par un domaine de fonctionnement, pas par un adjectif

Annoncez la position sur la demande de Val d’Orme, puis décrivez les opérations et la courbe testées, la version, la population de données, les critères de réussite et la zone observée. Indiquez le comportement à la pointe, le délai d’ajout de capacité et la récupération. Les hypothèses ou limites qui influencent l’évaluation apparaissent dans la partie prescrite de l’offre.

Une réponse autorisée pourrait expliquer que la version proposée a subi une séquence reproduisant contrôle d’éligibilité, dépôt de justificatifs, calcul et consultation du statut sur une population représentative. Elle donnerait une plage de dossiers correctement achevés, les percentiles retenus, les erreurs, l’âge des files et le délai de retour après saturation. Si une partie des 65 000 voyageurs repose encore sur un modèle, elle serait présentée comme telle avec un essai avant ouverture. Aucune phrase ne promettrait une charge sans borne.

Le dossier technique ne décide pas seul de l’offre. Le responsable performance valide méthode et données. Produit confirme la version. Exploitation accepte la zone, les alertes et la réaction en saturation. Sécurité fixe le détail communicable. Finance et commerce valident le coût d’extension. Le délégataire contractuel approuve la formulation exacte et ses conditions. Le niveau de service et ses recours restent une décision distincte.

**Matrice de validation de la réponse**

| Élément affirmé | Autorité requise | Condition avant remise |
| --- | --- | --- |
| Charge et résultat | Performance et produit | Essai versionné, calcul reproductible et écarts visibles |
| Zone d’exploitation | Propriétaire du service | Marge, surveillance, saturation et récupération acceptées |
| Voie d’extension | Ingénierie, fournisseur, finance et commerce | Action, délai, coût, dépendances et recette approuvés |
| Texte destiné à l’acheteur | Délégataire de l’offre | Formulation exacte alignée sur preuve, prix et contrat |

## Résultats utiles

- La prévision de l’acheteur est décomposée en opérations, taux d’arrivée, concurrence, durée, données, géographie et appels externes.
- Une session ouverte, une requête technique et un dossier d’indemnisation terminé restent trois mesures distinctes.
- La preuve indique la version, les fonctions, l’état des données, la classe d’environnement, le profil de charge, la durée et les répétitions.
- Le débit utile exclut les échecs, doublons, abandons et nouvelles tentatives selon une règle conservée.
- Les percentiles de délai sont lus avec erreurs, exactitude du résultat, files et limites des dépendances.
- La zone proposée se place sous le point où le débit plafonne, les queues vieillissent ou les délais se dégradent.
- La réaction à la pointe décrit détection, mise à disposition, échauffement, répartition et retour à l’état normal.
- Les demandes supérieures suivent une voie d’extension avec responsable, délai, coût, conditions et test d’acceptation.
- Le texte remis répond à l’évaluation tout en respectant les limites de sécurité, de prix et d’autorité.

## Déroulement

1. **Fixer la question et le moment de vérité.** Conservez le texte, les définitions, le lot, la population, la période de pointe, la version de l’offre, les critères, les annexes et le champ de réponse.
2. **Décrire les parcours et la courbe d’arrivée.** Répartissez consultation, dépôt, contrôle, calcul, justificatif, notification et traitement différé avec leurs volumes et leur chronologie.
3. **Établir la représentativité du test.** Comparez version, fonctions, données, autorisations, réseau, région, dépendances et politiques de capacité avec le service offert.
4. **Définir réussite, seuils et arrêt.** Fixez achèvement métier, percentiles, erreurs, exactitude, âge des files, signaux de saturation, répétitions et limites de sécurité.
5. **Exécuter la charge dans le temps.** Mesurez régime ordinaire, ouverture soudaine, pointe tenue, durée prolongée, saturation contrôlée et retour à la normale.
6. **Délimiter la zone exploitable.** Repérez le premier palier où le travail utile ne suit plus, où les fins de distribution s’allongent ou où les files vieillissent.
7. **Tester l’ajout de capacité.** Chronométrez détection, décision, fourniture, préparation, prise de charge, contraintes fixes, coût et réduction après la pointe.
8. **Faire approuver la réponse exacte.** Rapprochez preuve, niveau de service, sécurité, exploitation, prix et contrat avant de libérer une formulation bornée.

## Décisions clés

- Quel résultat concret le voyageur ou l’agent doit-il obtenir sous charge?
- Les 65 000 personnes représentent-elles des comptes, sessions, arrivées, demandes simultanées ou dossiers achevés?
- Quelle part consulte une information, dépose une demande, ajoute une image, reprend un brouillon ou interroge le statut?
- Quel est le pic par minute, sa rampe, sa durée, sa répartition géographique et son évolution prévue?
- Quelles tailles, qualités d’image, périodes historiques et relations de données modifient le coût du traitement?
- Quels contrôles de titre, paiement, messagerie ou lutte contre la fraude participent au parcours?
- La version, la configuration et l’environnement testés représentent-ils l’offre au jour de la remise?
- Quel événement prouve qu’un dossier a été stocké, contrôlé, calculé et rendu consultable?
- Quels délais de queue, percentiles, erreurs et contrôles d’exactitude bornent la zone acceptable?
- Quel est le premier goulot constaté et comment le générateur de charge a-t-il été écarté?
- Que deviennent les demandes acceptées, différées, refusées et répétées au-delà de la zone?
- Quelle autorité valide le résultat, l’extension, son prix et le détail communicable?

## Risques

- Le nombre de voyageurs éligibles est présenté comme une concurrence active.
- Une consultation légère représente abusivement le dépôt complet avec justificatifs.
- Le test utilise une base neuve et évite les recherches dans plusieurs années de transactions.
- Le taux de requêtes additionne relances, sondages et échecs sans mesurer les dossiers utiles.
- Les erreurs sortent du calcul de délai et améliorent artificiellement les percentiles.
- Un essai bref finit avant l’accumulation du contrôle d’images et du rapprochement financier.
- L’ajout de capacité s’active après la limite d’expérience promise aux voyageurs.
- Un service externe ou une file ordonnée fixe la limite malgré les ressources ajoutées ailleurs.
- Le terme dégradation gracieuse masque une perte de fonction qui rend le dossier inutilisable.
- La réponse expose un seuil de protection ou un schéma interne inutile à l’évaluation.
- Une preuve ancienne survit à une nouvelle version ou à une modification du parcours financier.

## Indicateurs

- hypothèses de charge reliées à une source, une période, une plage et un décideur
- dossiers d’indemnisation correctement achevés par intervalle et par type de parcours
- p50, p95 et p99 du dépôt, du contrôle, du calcul et de la consultation du statut
- refus métier, échecs techniques, expirations, abandons, relances et doublons
- profondeur et âge maximal des files pendant la pointe puis le rattrapage
- écarts de calcul, pièces perdues, statuts incohérents et écritures dupliquées
- gain de débit utile obtenu par palier de capacité ajouté
- délai entre le signal d’extension et le retour dans la zone stable
- affirmations remises avec preuve versionnée, conditions et approbateur
- promesses de capacité illimitée dans la copie finale; objectif zéro

## Questions fréquentes

### Un test de 65 000 utilisateurs simultanés suffit-il?

Seulement s’il représente les parcours, arrivées, pièces, données, dépendances, durée, version et règles de réussite de l’offre. Le nombre seul ne décrit pas la charge.

### Peut-on utiliser les requêtes par seconde comme débit?

Oui comme mesure technique, mais ajoutez les dossiers correctement terminés. Retirez ou classez relances, doublons, erreurs et abandons pour ne pas confondre trafic et résultat.

### Faut-il publier le p95 ou le p99?

Choisissez le percentile demandé ou justifié par le parcours, définissez sa population et montrez assez de distribution pour révéler la queue. Associez toujours erreurs et exactitude.

### L’acheteur peut-il exiger toute la topologie de production?

Répondez selon les pièces et la décision de sécurité. La portée, la représentativité et la méthode peuvent être vérifiables sans publier adresses, accès, seuils de défense ni relations exploitables.

### Une plateforme élastique a-t-elle une capacité illimitée?

Non. Détection, fourniture, préparation, état, quotas, dépendances, zones et budget limitent l’extension. Mesurez le délai avant gain de travail utile.

### Comment utiliser un essai réalisé sur un environnement réduit?

Exposez les différences, prouvez les relations proportionnelles, conservez les limites fixes et planifiez une validation. Une extrapolation non testée reste un modèle, pas un résultat.

### Quand faut-il rejouer le test?

Après une modification matérielle de version, données, parcours, charge, environnement, dépendance, quota, règle d’extension ou observation, et lorsque le besoin acheteur change.

### La preuve de capacité crée-t-elle un engagement de niveau de service?

Non. Elle soutient la faisabilité sous conditions. La cible contractuelle, la mesure, les exclusions, les recours, le prix et le pouvoir d’engager suivent leur propre validation.


## Sources primaires

- [ISO/IEC 25010:2023 sur le modèle de qualité des produits](https://www.iso.org/standard/78176.html), Organisation internationale de normalisation
- [ISO/IEC 25023:2016 sur la mesure de la qualité des systèmes et logiciels](https://www.iso.org/standard/35747.html), Organisation internationale de normalisation
- [ISO/IEC 25030:2019 sur les exigences de qualité](https://www.iso.org/standard/72116.html), Organisation internationale de normalisation
- [ISO/IEC 25040:2024 sur le cadre d’évaluation de la qualité](https://www.iso.org/standard/83467.html), Organisation internationale de normalisation
- [ISO/IEC/IEEE 29119-1:2022 sur les concepts des tests logiciels](https://www.iso.org/standard/81291.html), Organisation internationale de normalisation
- [ISO/IEC/IEEE 29119-2:2021 sur les processus de test logiciel](https://www.iso.org/standard/79428.html), Organisation internationale de normalisation
- [Présentation ISO de la série ISO/IEC/IEEE 29119](https://committee.iso.org/sites/jtc1sc7/home/projects/flagship-standards/isoiecieee-29119-series.html), Organisation internationale de normalisation
- [NIST SP 500-307 sur la description des métriques de services cloud](https://www.nist.gov/publications/cloud-computing-service-metrics-description-0), National Institute of Standards and Technology
- [Pratiques Google SRE de planification de capacité et de surcharge](https://sre.google/sre-book/service-best-practices/), Google Site Reliability Engineering
- [Chapitre Google SRE sur les défaillances en cascade et le délestage](https://sre.google/sre-book/addressing-cascading-failures/), Google Site Reliability Engineering
- [Chapitre Google SRE sur les lancements de produit à grande échelle](https://sre.google/sre-book/reliable-product-launches/), Google Site Reliability Engineering
- [Guide Azure Well-Architected sur les tests de performance](https://learn.microsoft.com/en-us/azure/well-architected/performance-efficiency/performance-test), Microsoft Learn
- [Guide Azure Well-Architected sur la planification de capacité](https://learn.microsoft.com/en-us/azure/well-architected/performance-efficiency/capacity-planning), Microsoft Learn
- [Guide Azure Well-Architected sur les objectifs de performance](https://learn.microsoft.com/en-us/azure/well-architected/performance-efficiency/performance-targets), Microsoft Learn
- [Guide Azure Architecture Center sur la mise à l’échelle horizontale](https://learn.microsoft.com/en-us/azure/architecture/guide/design-principles/scale-out), Microsoft Learn
- [Conventions sémantiques OpenTelemetry pour les métriques HTTP](https://opentelemetry.io/docs/specs/semconv/http/http-metrics/), OpenTelemetry
- [RFC 8239 de l’IETF sur la méthodologie de benchmark des centres de données](https://datatracker.ietf.org/doc/html/rfc8239), Internet Engineering Task Force
- [Procurement Act 2023, article 23 sur les critères d’attribution](https://www.legislation.gov.uk/ukpga/2023/54/section/23), UK Legislation
- [Guide britannique actuel sur l’évaluation des offres concurrentielles](https://www.gov.uk/government/publications/procurement-act-2023-guidance-documents-procure-phase/assessing-competitive-tenders-html), UK Cabinet Office
- [Directive 2014/24/UE sur la passation des marchés publics](https://eur-lex.europa.eu/eli/dir/2014/24/oj/fra), Union européenne
- [§ 31 VgV allemand sur le cahier des charges](https://www.gesetze-im-internet.de/vgv_2016/__31.html), Ministère fédéral allemand de la Justice et Office fédéral de la Justice
- [Code de la commande publique, article R2152-7 en vigueur](https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000045739587), Légifrance


## Articles complémentaires

- [Que prouve vraiment un rapport d’assurance dans une offre ?](https://zephior.com/fr/insights/use-third-party-assurance-in-a-bid)
- [Répondre sur l’IA responsable avec des contrôles éprouvés](https://zephior.com/fr/insights/answer-an-rfp-responsible-ai-question)
- [Rédiger un résumé exécutif que l’offre peut prouver](https://zephior.com/fr/insights/align-an-executive-summary-with-bid-evidence)
- [Prouver une performance de niveau de service dans une offre](https://zephior.com/fr/insights/evidence-service-level-performance-in-a-bid)