Cartographier avant de déplacer
Un dispositif peut conserver une collecte dans le navigateur, envoyer les événements à un serveur puis les transmettre à des destinataires. Le mode Consentement communique des états et adapte certains comportements ; il ne fournit pas à lui seul une bannière de choix ni une validation juridique.
| Étape | Contrôle | Preuve recherchée |
|---|---|---|
| Navigateur ou application | Champs et choix collectés. | Requêtes réellement émises. |
| Serveur de collecte | Validation, filtrage et accès. | Événements acceptés ou rejetés. |
| Destination | Données effectivement transmises. | Charge utile et règles de consentement. |
| Exploitation | Conservation, droits et reprise. | Tests de suppression, panne et accès. |
Tester ce qui est réellement envoyé
- Établissez une liste de champs autorisés et de destinataires par finalité. Inspectez URL, paramètres, identifiants et journaux avant toute transmission ; ne supposez pas qu’un filtrage existe par défaut.
- Testez acceptation, refus et changement de choix de bout en bout. Vérifiez le comportement du navigateur, du conteneur serveur et de chaque destination.
- Rapprochez événements reçus, acceptés et transmis. Testez doublons, pertes, panne et reprise, puis mesurez le coût et la charge du serveur.
Évaluer les gains et les obligations séparément
Vérifiez les performances sur des parcours comparables : une collecte initiale dans le navigateur peut rester nécessaire. Un domaine de première partie n’est pas une exemption. En France, l’exemption de certains outils de mesure d’audience est conditionnelle ; elle ne couvre pas automatiquement un marquage publicitaire.
Références primaires
- Google Tag Manager — Server-side tagging introduction [EN]
- Google Tag Manager — Server-side Consent Mode [EN]
- CNIL — Cookies et mesure d’audience [FR]
Tagging serveur : contrôler les flux réels
Déplacer des tags vers un serveur ne rend pas automatiquement la mesure conforme ni minimale. Les requêtes émises, les destinataires, les identifiants et le comportement après refus doivent être vérifiés sur l’installation effective.
- Cartographier navigateur, serveur de collecte, fournisseurs et données transmises.
- Tester avant choix, après refus et après retrait du consentement.
- Comparer la configuration aux finalités déclarées et aux conditions CNIL pertinentes.
Référence primaire : CNIL — Outils de mesure d’audience et traceurs. Méthode connexe : consulter le guide pratique.
Séparer débit, budget et concurrence
Une limite en requêtes par minute ne protège pas forcément une opération très coûteuse. Définissez les unités utiles et testez la reprise après dépassement, avec un budget d’essais borné.
- Unité, fenêtre, identité et route
- Réponse, délai et message utilisateur
- Budget d’essais, doublons et arrêt
- Charge testée, refus et retour à la normale
Cas de recette à reproduire
Exemple fictif : ces données ne décrivent aucun client ni résultat réel.
Voir les données du cas
{
"http_status": 429,
"retry_after_seconds": 30,
"workers": 20,
"retry_budget": 3,
"retry_budget_scope": "per_worker_retries_excluding_initial_request",
"scheduling_example": {
"response_received_at_seconds": 0,
"illustrative_retry_seconds": [
30,
31,
32,
33,
34
],
"workers_per_second": 4,
"alternative_deadline_seconds": 25,
"total_attempts_if_all_retries_used": 80
}
}Décision attendue
Respecter l’attente de 30 secondes ; échelonner les reprises des 20 travailleurs et borner leur budget.
Vingt clients : répartir la reprise et compter les tentatives
Exemple fictif : 20 travailleurs reçoivent chacun à +0 s une réponse 429 avec Retry-After: 30. Les horaires ci-dessous illustrent une répartition possible, sans garantir la capacité du serveur. Le budget est de 3 reprises par travailleur, en plus de sa requête initiale.
| Politique | Calcul ou horaire | Ce que cela change |
|---|---|---|
| Reprise simultanée | 20 × 1 = 20 @ +30 s | Attendre 30 secondes respecte le délai, mais les 20 requêtes repartent au même instant : la rafale peut revenir. |
| Reprise répartie | 4 × 5 = 20 @ +30…+34 s | Quatre requêtes par seconde pendant cinq secondes répartissent les 20 reprises, sans en diminuer le nombre. Ce calendrier illustratif ne remplace pas une politique de temporisation avec variation aléatoire. |
| Échéance à 25 secondes | 25 s < 30 s → 0 | Si le temps restant est inférieur aux 30 secondes demandées, arrêter ou différer selon le contrat. Ne pas raccourcir le délai pour tenir l’échéance. |
| Budget maximal | 20 × (1 + 3) = 80 | Si toutes les tentatives sont utilisées, 20 requêtes initiales et 60 reprises donnent 80 requêtes au total. Le plafond ne garantit ni réussite ni innocuité d’une répétition. |
Procédure de vérification
- Relevez quota, portée et budget de reprise.
- Épuisez le quota uniquement dans un test autorisé.
- Conservez 429, Retry-After et chronologie des reprises bornées. Distinguez la limitation technique du résultat métier : un quota épuisé ne doit pas devenir une réponse annonçant un stock nul.
- Dans une simulation sans charge externe, comptez les tentatives de quatre couches limitées chacune à trois appels totaux.
- Faites expirer une tâche fictive en file et vérifiez qu’elle ne démarre pas comme nouvelle opération.
- Réintroduisez progressivement les travaux autorisés après une panne simulée et conservez appels, échéances et résultats métier uniques.
Un code 429 suffit-il à protéger le service ?
Non. Il décrit un refus. Il faut aussi contrôler coût, concurrence, files et comportement des clients.
Référence primaire : IETF — RFC 6585, HTTP 429. Méthode connexe : consulter le guide pratique.
Impact carbone logiciel : définir le périmètre avant de comparer
Séparer volume transféré, énergie, émissions et service rendu pour éviter les gains environnementaux invérifiables.
Cas de recette à reproduire
Exemple fictif : ces données ne décrivent aucun client ni résultat réel.
Voir les données du cas
{
"functional_unit": "accepted_task",
"energy_kWh": 2,
"intensity_gCO2e_per_kWh": 100,
"embodied_gCO2e": 50,
"accepted_tasks": 100,
"SCI_gCO2e_per_task": 2.5
}Décision attendue
Le scénario donne (2 × 100 + 50)/100 = 2,5 gCO2e par tâche, dans le périmètre déclaré seulement.
Procédure de vérification
- Fixez périmètre, unité fonctionnelle et facteurs utilisés.
- Séparez énergie, émissions incorporées et résultats acceptés.
- Conservez hypothèses, provenance et calcul sans compensation implicite.
Référence primaire : Green Software Foundation — Software Carbon Intensity. Méthode connexe : consulter le guide pratique.
API : éviter les reprises multipliées entre couches
Une application, son SDK, un proxy et un service peuvent chacun réessayer le même appel. Dans un exemple fictif où quatre couches font chacune trois tentatives au total, jusqu’à 81 appels atteignent la dépendance en échec. La méthode ci-dessous ajoute un budget partagé et une échéance utile aux contrôles de quota existants.
- Cartographiez application, SDK, proxy et dépendances avec leurs tentatives automatiques. Choisissez la couche responsable et désactivez ou coordonnez les reprises supplémentaires selon le contrat. Comptez la première tentative dans le budget total. Conservez l’identifiant métier et vérifiez les effets incertains avant de relancer une opération non idempotente.
- Définissez une échéance de bout en bout couvrant attente, connexion et traitement, avec les limites réelles du client utilisé. Refusez les tâches périmées avant leur admission en file. Une annulation locale ne prouve pas que le serveur s’est arrêté : rapprochez son état. Testez le retour progressif du trafic après panne sans réactiver simultanément toutes les files.
Trois tentatives à chaque couche font-elles trois tentatives au total ?
Non. Elles peuvent se multiplier. Dans la chaîne fictive de quatre couches, trois tentatives totales par couche donnent jusqu’à 3⁴ = 81 appels à la dernière dépendance.
L’expiration d’une tâche annule-t-elle son effet distant ?
Pas nécessairement. Elle doit empêcher les nouveaux travaux devenus inutiles ; un traitement distant déjà commencé exige un contrôle de son état et une compensation adaptée si elle existe.
Référence primaire : AWS — Timeouts, retries, and backoff with jitter. Méthode connexe : consulter le guide pratique.