Périmètre sûr : ce guide vise vos propres applications, vos environnements de QA et de préproduction, ou des systèmes pour lesquels vous disposez d'une autorisation écrite.
Un tracker de publication multilingue ne dérive jamais d'un seul coup : il dérive une ligne à la fois. Une locale republiée à la main, un slug corrigé dans le CMS, et le fichier ne décrit plus la réalité. Réconcilier, c'est comparer ce que dit votre tracker et ce que renvoie chaque application linguistique, puis n'écrire que les écarts. Quand ce contrôle passe derrière un formulaire protégé, l'API CaptchaAI fournit le token dans la même session que la requête.
Les trois propriétés d'un tracker multilingue fiable
Trois propriétés suffisent, et elles se vérifient en lisant le fichier :
- Idempotence — rejouer la passe sur un état inchangé produit le même fichier. Sinon, personne n'ose relancer après un échec partiel.
- Traçabilité — chaque ligne porte la date de son dernier contrôle en direct, pas la date de la passe. Une ligne vérifiée il y a trois semaines doit se voir comme telle.
- Granularité par locale — un incident sur
frne bloque jamaises: verrou, journal et compteur d'échecs sont tenus par locale.
Cas courant dans les équipes francophones : un site publié en français, néerlandais et allemand pour le marché belge, avec un seul fichier de suivi. Une republication manuelle côté nl réécrit l'horodatage global, et les deux autres locales passent pour vérifiées. Une clé composite (slug, locale) règle le problème.
Le modèle de réconciliation : une source, plusieurs miroirs
Le tracker est la source de vérité déclarative ; chaque locale est un miroir observable. Le script ne pousse rien tant qu'il n'a pas lu.
| Étape | Entrée | Sortie attendue |
|---|---|---|
| Inventaire | Sources et tracker | Liste (slug, locale) |
| Relevé en direct | Page publique de la locale | Code HTTP, titre, date |
| Diff | Inventaire + relevé | Manquant, obsolète, orphelin |
| Application | Écarts validés | Tracker réécrit, journal |
Le diff ne rend que trois verdicts. Manquant : la ligne existe, la page ne répond pas — l'erreur est côté publication. Obsolète : la page répond, mais son titre ou sa date ne correspondent plus — le cas le plus fréquent, et le seul qui se corrige automatiquement sans risque. Orphelin : la page est en ligne alors qu'aucune ligne ne la revendique — c'est le processus qu'il faut corriger, pas seulement le fichier.
Où stocker la clé API et les secrets de synchronisation
La clé CaptchaAI vit dans un coffre (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) ou dans un secret CI, monté en variable d'environnement au runtime. Elle n'apparaît jamais dans le dépôt. La facturation repose sur les threads : BASIC ($15/mois, 5 threads) suffit à une passe nocturne, STANDARD ($30/mois, 15 threads) absorbe une réconciliation parallélisée sur dix locales. Les prix restent en dollars US.
Prévoyez la rotation dès le premier jour : le script lit la clé au démarrage, jamais au milieu d'une boucle. Si vos locales sont réparties sur plusieurs comptes CMS, gardez un secret par application, nommé d'après la locale — un identifiant partagé entre fr et be-nl rend tout incident indémêlable dans les journaux.
Exemple : vérifier le solde avant une passe
Une passe interrompue à mi-parcours laisse le tracker partiellement écrit.
import os
import requests
API_KEY = os.environ['CAPTCHAAI_KEY']
def get_balance() -> float:
resp = requests.post(
'https://api.captchaai.com/getBalance',
json={'clientKey': API_KEY},
timeout=15,
)
resp.raise_for_status()
return float(resp.json().get('balance', 0))
Appelez-la une fois au démarrage et comparez le solde au coût estimé de la passe. Si la marge est insuffisante, arrêtez avant la première écriture plutôt qu'après la troisième locale.
Journalisation, métriques et obligations RGPD
Instrumentez chaque appel : durée d'obtention du token, code retour HTTP, identifiant de tâche. Séparez les journaux par environnement et corrélez-les à votre traçage OpenTelemetry. Côté conformité, un tracker n'a aucune raison de contenir des données personnelles : ne journalisez ni e-mail d'éditeur, ni adresse IP de relecteur, et fixez une durée de conservation. Réflexe RGPD standard, que vos serveurs tournent chez OVHcloud, Scaleway ou en région AWS eu-west-3 (Paris).
Contrôles avant d'écrire dans le tracker
- Lancez d'abord la passe en lecture seule et relisez le diff : aucune écriture tant qu'un humain n'a pas vu le nombre de lignes touchées.
- Fixez un plafond d'écritures par passe (5 % des lignes, par exemple) et faites échouer le job au-delà — au-dessus de ce seuil, c'est le relevé qui est faux, pas le tracker.
- Couvrez les erreurs transitoires par un retry idempotent avec backoff exponentiel borné, jamais par une reprise qui repart de zéro.
- Écrivez le fichier de façon atomique (fichier temporaire puis renommage) pour qu'une interruption ne laisse jamais un tracker tronqué.
- Faites relire le diff par la personne qui gère la locale concernée quand l'écart porte sur autre chose qu'une date.
Dépannage des écarts de tracker les plus fréquents
| Symptôme | Cause probable | Correctif |
|---|---|---|
| Locale entière « obsolète » | Fuseaux horaires divergents | Horodatages en UTC |
| Slug en direct, absent du tracker | Publication hors pipeline | Ajoutez la ligne, alertez sur l'origine |
| Token refusé après résolution | Session différente du défi | Même client HTTP de bout en bout |
| Une locale rebascule à chaque passe | Deux sources écrivent la même ligne | Une seule autorité par (slug, locale) |
FAQ
Comment détecter un écart entre le tracker et la locale en direct ?
Comparez trois champs : code HTTP, titre et date de mise à jour. Si l'un diverge, marquez la ligne comme suspecte : une correction automatique sur signal faible transforme une anomalie en réécriture massive.
Faut-il un fichier de suivi par langue ou un fichier unique ?
Un fichier par langue, plus un index global. Cette découpe limite les conflits de fusion et permet de relancer une seule locale après un incident.
Que faire si l'API renvoie une erreur transitoire pendant la passe ?
Appliquez un backoff exponentiel borné : trois tentatives, délai doublé à chaque essai, plafond à 30 s. Tracez chaque échec avec son identifiant de tâche, puis vérifiez le réseau et le solde de votre clé.
Peut-on lancer la synchronisation depuis un job planifié ?
Oui, à condition qu'un verrou empêche deux passes simultanées. Planifiez-la hors des fenêtres de déploiement et faites échouer le job plutôt que de terminer sur un tracker partiel.
À quelle fréquence relancer une passe de réconciliation ?
Une passe complète par nuit suffit dans la plupart des équipes, complétée par une passe ciblée sur la locale concernée après chaque publication. Au-delà, vous consommez du quota et du temps de relecture pour un gain nul.
Guides connexes
- Le démarrage rapide CaptchaAI
- Tester les CAPTCHA en environnement autorisé
- Vérifier vos formulaires via l'endpoint API
- La résolution CAPTCHA en CI
- Résoudre reCAPTCHA v2 avec l'API
Une passe de réconciliation fiable commence par un token obtenu proprement. – Obtenez votre clé CaptchaAI.