La PR backend #634, liée au ticket #633, raccorde le moteur R1 et le détecteur D2 utilisés par l'administration à POST /scan-lab?tcg=pokemon. Le contrat mobile est conservé : aucune modification du frontend. Le backend choisit le modèle, enrichit les cartes, déduplique les résultats et décide du niveau de confiance.

Activation et retour arrière

• Le comportement par défaut reste SCAN_CARD_ENGINE=legacy.
• Pour activer : SCAN_CARD_ENGINE=r1 et SCAN_R1_URL pointant vers le service interne accessible depuis l'API, puis recréer/redéployer l'API avec cet environnement.
• Pour revenir en arrière : remettre SCAN_CARD_ENGINE=legacy et recréer/redéployer l'API. Un simple redémarrage ne recharge pas les variables Compose modifiées.
• Conserver le service et l'index historiques. Une erreur, un délai de cinq secondes dépassé ou une réponse invalide du service R1 déclenche le chemin historique dans la même requête.
• Les résultats R1 valides mais incertains ou sans correspondance ne déclenchent pas une seconde tentative avec l'ancien moteur.
• One Piece et la sélection automatique du TCG restent sur le moteur historique. La couverture japonaise de R1 n'est pas validée.

Vérifications

Node 22.23.4 : 15 tests ciblés réussis ; suite API 1 648 réussis, 42 ignorés, aucun échec ; ingestion 569 réussis ; vérification TypeScript et contrôle des espaces du diff réussis.

La suite E2E complète PostgreSQL/Redis reste à vérifier : Docker est absent du poste et la suite échoue lors de sa préparation. Après déploiement, le handler a été vérifié dans l'image en service avec la vraie base en lecture seule et le service R1/D2 : reconnaissance de bw2-9 via R1 en environ 747 ms, chemin historique et repli simulé réussis. Santé et préparation publiques : HTTP 200 ; scan sans authentification : HTTP 401. Un test authentifié sur téléphone et une évaluation de précision sur photos réelles restent à effectuer.

État et limites

La PR backend #634 et la PR documentation #365 ont été fusionnées sur staging le 3 novembre 2026. R1 est désormais activé sur l'API publique Docker via l'image skns-api:r1-b5a37ee (base déployée 25e56308 + changements R1 de #634). Le défaut du code reste legacy, mais la configuration du serveur sélectionne r1.

La PR d'inscription #632 n'a pas été déployée : sa migration 0054 n'est pas appliquée. Une branche de livraison deploy/scan-r1-20261103 isole les changements R1 pour préserver les inscriptions sans migration. L'API Kubernetes staging n'a pas été redéployée. L'image et la configuration précédentes sont conservées pour un retour arrière.

Voir le guide de déploiement, d'activation et de retour arrière pour le raccordement au service de Georgic et les vérifications avant activation.

Aucun changement de base, d'index historique ou de code mobile. Avant activation générale, vérifier l'accès réseau API → service R1, l'intégration avec le catalogue réel et un échantillon de photos utilisateur. Une panne répétée de R1 peut ajouter cinq secondes avant chaque repli ; aucun coupe-circuit n'est ajouté dans cette PR.