Snag : checklist avant mise en production

Date : 3 octobre 2026.

Périmètre : application mobile, backend, VPS et site vitrine. Les contrôles desktop s'appliquent avant la sortie de cette plateforme ; ils ne bloquent pas une sortie exclusivement mobile. Les contrôles de paiement s'appliquent dès qu'une offre payante est activée.

Ce document rassemble les recommandations discutées et les compléments à vérifier avant lancement. Ce n'est ni un audit de l'état actuel, ni une certification de sécurité ou de conformité. Aucun nouveau test du VPS, des dépôts ou des builds n'a été effectué pour cette checklist.

Document complémentaire : Confidentialité, cookies, valorisation et statistiques de scans.

1. Comment utiliser cette checklist

• Toutes les cases sont initialement à vérifier : elles ne signifient pas qu'un défaut a été constaté.
• Pour chaque contrôle, conserver un responsable, une date, la version testée, une preuve et le résultat : validé, échoué ou non applicable avec justification.
• P0 : bloquant si le contrôle révèle un risque critique pour les données, les accès, la disponibilité ou les coûts.
• P1 : nécessaire avant l'ouverture du périmètre concerné ; une exception doit être explicitement acceptée avec mesures compensatoires et échéance.
• P2 : renforcement à planifier ; peut devenir P0/P1 selon l'exposition et le risque réel.
• Une checklist cochée sans preuve ne vaut pas validation.

2. API : sécuriser les opérations, pas seulement identifier le client

Limite importante

Une API utilisée par des téléphones sur Internet doit être joignable depuis leurs réseaux. On ne peut pas garantir qu'elle sera appelée exclusivement par l'application légitime. Un attaquant peut reproduire les appels ou utiliser un appareil réel.

Le bon objectif est de réserver les données et opérations aux utilisateurs autorisés, renforcer l'intégrité du client et plafonner les abus. CORS protège certains usages dans un navigateur ; il ne bloque pas un script, un autre client natif ou un appel direct. Un User-Agent, un en-tête personnalisé ou une clé globale embarquée dans l'application n'est pas une preuve fiable.

Contrôles d'accès et authentification

• [ ] P0 Tester avec deux comptes : A ne peut lire, modifier, ajouter ou supprimer aucune donnée privée de B, même en substituant des identifiants dans les requêtes.
• [ ] P0 Tester aussi les classeurs, historiques, valorisations, exports et liens de partage lorsqu'ils sont gérés côté serveur.
• [ ] P0 Vérifier que les rôles utilisateur ne permettent pas les opérations administratives ou les imports.
• [ ] P0 Vérifier les jetons manquants, invalides, expirés et révoqués, ainsi que leur invalidation effective après suppression du compte.
• [ ] P1 Vérifier le stockage sécurisé des jetons sur chaque plateforme ; ne pas conserver de secret fournisseur dans l'application.
• [ ] P1 Limiter la création des comptes/appareils, la récupération de compte, l'envoi de mails et les tentatives de connexion. Un compte anonyme par appareil n'empêche pas la création automatisée de nombreux comptes.
• [ ] P1 Tester une récupération ou un changement d'appareil sans prise de contrôle du compte d'un tiers ni perte silencieuse de collection.
• [ ] P1 Faire appliquer droits PRO et quotas par le backend, pas seulement par l'interface.

Anti-abus et validation des entrées

• [ ] P0 Borner les scans, demandes de prix et autres appels coûteux : quotas, débit, simultanéité, délai maximal et budget fournisseur.
• [ ] P1 Combiner limites par compte et IP ; ajouter un signal d'appareil validé si pertinent. Tenir compte des réseaux partagés et des créations multiples de comptes.
• [ ] P1 Vérifier la confiance accordée aux en-têtes de proxy/IP pour éviter de contourner les limites.
• [ ] P1 Limiter pagination, exports, taille des requêtes, images, dimensions décodées et fichiers malformés.
• [ ] P1 Valider types et champs côté serveur ; tester injections SQL, champs supplémentaires, chemins de fichiers et uploads invalides.
• [ ] P1 Si le serveur télécharge des URL fournies par le client, tester les accès interdits aux réseaux internes et aux métadonnées d'infrastructure ; ne pas autoriser les destinations arbitraires.
• [ ] P1 Vérifier que les erreurs n'exposent pas requêtes SQL, secrets, traces détaillées ou chemins internes.
• [ ] P1 Prévoir un mécanisme de coupure des appels externes ou du scan en cas d'abus/coût anormal, sans perdre les collections.

Sources : OWASP : sécurité REST, OWASP : API Security Top 10.

Intégrité des applications

• [ ] P2 / selon risque Évaluer Play Integrity sur Android et App Attest sur iOS : validation côté serveur, lien avec l'action demandée et protection contre le rejeu.
• [ ] P1 si activé Tester builds de développement, TestFlight/Play testing, production et indisponibilité du fournisseur d'attestation. Observer les rejets avant enforcement généralisé.
• [ ] P1 si activé Définir le comportement en cas d'attestation indisponible ou invalide sans créer un contournement général sur les opérations sensibles.
• [ ] P2 Obfuscation et durcissement des builds selon la plateforme. Ce sont des protections complémentaires, pas un remplacement des contrôles backend.

Sources : Google : Play Integrity, Apple : App Attest.

3. VPS, réseau et administration

• [ ] P0 Vérifier les ports depuis une machine extérieure : IPv4 et IPv6, publications Docker et règles du fournisseur incluses.
• [ ] P0 PostgreSQL, Redis, services de modèles, diagnostics et administration ne sont pas publiquement accessibles.
• [ ] P1 L'entrée API destinée aux clients passe par HTTPS ; vérifier certificats, renouvellement, proxy et absence de contournement direct vers les ports internes.
• [ ] P1 Administration via SSH par clés et accès privé/VPN lorsque possible ; tester un second accès avant toute modification susceptible de verrouiller le serveur.
• [ ] P1 Réduire les accès privilégiés, révoquer les accès inutiles et savoir qui possède sudo ou l'accès Docker, qui équivaut généralement à un accès root.
• [ ] P1 Protéger les comptes GitHub, hébergeur, DNS et stores avec MFA et prévoir une récupération d'accès maîtrisée.
• [ ] P1 Vérifier isolation des conteneurs, privilèges, volumes montés, ressources CPU/RAM et permissions des fichiers sensibles.
• [ ] P1 Examiner paquets système, images de base et correctifs disponibles ; appliquer les changements après validation et sauvegarde, pas pendant un audit sans accord.

4. Dépendances, secrets et chaîne de livraison

• [ ] P0 Rechercher les secrets dans le code, l'historique Git, les journaux CI, artefacts et bundles mobiles ; révoquer les secrets exposés, ne pas seulement supprimer le fichier.
• [ ] P1 Auditer dépendances directes/transitives, SDK natifs, images Docker et paquets système pour les versions réellement déployées.
• [ ] P1 Trier les alertes selon exposition, exploitabilité et impact. Une dépendance de build peut aussi présenter un risque pour la chaîne de livraison.
• [ ] P0 Corriger ou neutraliser toute vulnérabilité critique/élevée exploitable sur le périmètre avant ouverture ; documenter le traitement des autres alertes.
• [ ] P1 Installer depuis les fichiers de verrouillage, connaître les versions exactes et éviter les mises à jour majeures aveugles.
• [ ] P1 Vérifier les permissions CI, dépendances/actions externes, protections des branches et séparation des secrets staging/production.
• [ ] P1 Déployer un artefact identifié et testé : commit, version mobile et digest d'image lorsque disponible. Ne pas reconstruire une version différente de celle validée sans nouveau contrôle.

5. Sauvegarde, migration et retour arrière

• [ ] P0 Sauvegarder la base et les fichiers nécessaires à la récupération du produit, avec stockage chiffré hors du VPS et accès restreints.
• [ ] P0 Restaurer réellement sur un environnement isolé ; vérifier comptes, collections, images et fonctionnement de l'API après restauration.
• [ ] P1 Définir la perte de données acceptable (RPO), le délai de reprise visé (RTO), la fréquence et la conservation des sauvegardes.
• [ ] P1 Surveiller les échecs et tester régulièrement la restauration ; un snapshot sur le même hébergeur ne couvre pas seul tous les scénarios.
• [ ] P0 Tester les migrations sur une copie représentative, leurs verrouillages, leur durée et la compatibilité avec la version précédente.
• [ ] P1 Documenter déploiement, vérifications immédiates et retour arrière. Un tag Git ne restaure ni la base ni les volumes et n'annule pas une migration.
• [ ] P1 Éviter de restaurer aveuglément une ancienne base pour revenir à une ancienne API : cela peut perdre les nouvelles écritures et réintroduire des données supprimées.

Source : CNIL : sauvegarder.

6. RGPD, confidentialité et documents

• [ ] P1 Inventorier données, SDK, flux externes et stockages sur la vitrine, le mobile, le desktop concerné et le backend.
• [ ] P1 Tenir le registre applicable avec finalités, bases légales, données, destinataires, durées et droits.
• [ ] P1 Prévoir contrats de sous-traitance et encadrement des transferts hors EEE. Un VPS en Europe ne garantit pas que les autres prestataires restent dans l'EEE.
• [ ] P1 Publier mentions légales et politique de confidentialité complètes, accessibles sans connexion. Prévoir CGU et conditions PRO adaptées.
• [ ] P1 Vérifier les stockages nécessaires et traceurs facultatifs : pas de bandeau systématique si inutile, mais consentement préalable et retrait simple lorsqu'ils sont requis.
• [ ] P1 Séparer consentement facultatif, acceptation contractuelle et permissions caméra/notifications ; ne pas les confondre.
• [ ] P1 Expliquer envoi et conservation des photos de scan, diagnostics, éventuelle amélioration des modèles et partage public.
• [ ] P1 Tester accès, rectification, effacement et portabilité lorsqu'elle s'applique ; prévoir une procédure de réponse et de vérification d'identité proportionnée.
• [ ] P1 Vérifier les déclarations Apple App Privacy et Google Data Safety, SDK compris ; prévoir la suppression dans l'app et la ressource Web demandée par Google.
• [ ] P1 Définir les règles adaptées aux mineurs et aux pays visés. Le seuil français de 15 ans pour certains consentements n'est pas une interdiction générale d'usage.
• [ ] P1 Évaluer si une AIPD ou un DPO est requis selon les traitements réels ; ne pas les considérer automatiquement obligatoires ou inutiles.
• [ ] P1 Prévoir gestion des incidents et notification sous 72 heures lorsqu'une violation doit être notifiée à la CNIL.

Valorisation et statistiques de scans

• [ ] P1 Séparer gestion/valorisation de collection, historique personnel et statistiques internes dans la documentation.
• [ ] P1 Garder valorisation et données d'achat privées par défaut ; choisir explicitement ce qui figure dans un partage public.
• [ ] P1 Privilégier des compteurs carte + jour + nombre de scans, sans identifiant utilisateur, IP ni photo si ces éléments ne sont pas nécessaires.
• [ ] P1 Définir si le compteur mesure tentatives, scans réussis ou cartes confirmées ; traiter les doubles appels et abus.
• [ ] P1 Vérifier les risques de réidentification : un hash ou une agrégation très fine ne garantit pas l'anonymat.
• [ ] P1 Ne transmettre aux fournisseurs de prix que les caractéristiques nécessaires, pas l'identité du propriétaire ni toute sa collection.
• [ ] P1 Justifier la base légale de chaque traitement ; l'exécution du contrat ne couvre que ce qui est nécessaire au service, et l'intérêt légitime ne dispense pas du consentement aux traceurs non exemptés.

Batchs de conservation et suppression

• [ ] P1 Définir les durées avant de coder les purges ; aucun délai universel n'est fixé dans cette checklist.
• [ ] P1 Purger les photos, diagnostics, événements individuels et journaux arrivés à échéance.
• [ ] P1 Supprimer les comptes et leurs données associées, y compris historiques et données dérivées concernés, en distinguant conservations légalement justifiées.
• [ ] P1 Expirer les sessions et liens de partage selon les règles décidées ; supprimer les copies/cache personnels concernés.
• [ ] P1 Rendre les traitements idempotents, bornés, observables et testables en simulation ; empêcher les exécutions concurrentes dangereuses.
• [ ] P1 Tester relance après interruption et échec partiel ; vérifier les relations entre tables et fichiers sans supprimer les données d'autres utilisateurs.
• [ ] P1 Gérer le vieillissement des sauvegardes et la réapplication des suppressions après restauration, avec une procédure minimisant les données conservées à cette fin.

Sources : CNIL : premières étapes RGPD, durées, AIPD, violations. Détails et autres références dans la synthèse confidentialité liée en tête de document.

7. Tests métier et fiabilité des données

• [ ] P0 Tester ajout, modification, suppression et synchronisation sans perte ni doublons, y compris double clic, relance réseau et reprise après fermeture.
• [ ] P1 Tester mises à jour depuis une version précédente et conservation des données locales.
• [ ] P1 Tester la compatibilité des anciennes applications avec le nouveau backend ; les utilisateurs mobiles ne se mettent pas tous à jour immédiatement.
• [ ] P1 Vérifier identifiants stables des cartes, variantes, langue, état et gradation dans scan, collection et valorisation.
• [ ] P1 Tester précision et latence du scan sur un corpus représentatif FR et One Piece : reflets, éclairage, variantes proches et cartes hors catalogue.
• [ ] P1 Prévoir un résultat incertain ou une confirmation plutôt qu'une identification erronée enregistrée automatiquement.
• [ ] P1 Tester calculs de prix, quantités, devises, arrondis, doublons et valeurs manquantes. Une erreur fournisseur ou un prix absent ne doit pas devenir 0 EUR.
• [ ] P1 Distinguer valorisation connue et incomplète ; signaler source/date/fraîcheur et les estimations.
• [ ] P1 Vérifier les liens de partage : périmètre choisi, révocation, expiration prévue et absence de champs privés inattendus.

8. Charge, pannes et coûts

• [ ] P1 Définir la charge attendue, la marge de pointe et les objectifs de latence, puis tester en staging représentatif.
• [ ] P1 Mesurer erreurs, latence p95, files d'attente, connexions PostgreSQL, mémoire et temps de scan ; tester une surcharge contrôlée.
• [ ] P1 Tester fournisseur de prix lent/indisponible, Redis indisponible, redémarrage d'un service et disque proche de saturation.
• [ ] P1 Prévoir délais, retries bornés et protection contre les boucles de relance ; ne pas multiplier les appels externes en cas de cache indisponible.
• [ ] P1 Éviter que plusieurs demandes simultanées pour une carte déclenchent autant d'appels fournisseur ; définir fraîcheur et comportement en cas de données périmées.
• [ ] P0 Mettre des limites effectives aux appels payants et aux ressources coûteuses, avec alertes de budget et mécanisme de coupure.
• [ ] P1 Préserver la consultation des collections quand scan ou prix sont dégradés, si l'architecture le permet.

Les seuils de charge et budgets doivent être fixés par l'équipe ; aucun chiffre arbitraire ne constitue ici un critère de validation.

9. Builds, stores, vitrine et abonnement

• [ ] P1 Tester les artefacts de production signés sur les plateformes réellement lancées : pas seulement Metro, navigateur ou émulateur.
• [ ] P1 Vérifier URL de production, absence de debug et de données de test, signatures, numéros de version et permissions.
• [ ] P1 Tester caméra refusée, notifications refusées, réseau interrompu, écrans petits, tailles de texte, mode sombre et lecteurs d'écran sur les parcours essentiels.
• [ ] P1 Pour le desktop à sa sortie, vérifier signature et mécanisme de mise à jour sécurisé selon la distribution retenue.
• [ ] P1 Sur la vitrine, tester formulaires, mentions de collecte, liens juridiques, contenus externes et absence de traceurs facultatifs avant accord.
• [ ] P1 Si le PRO est activé, tester achat, restauration, renouvellement, expiration, annulation et remboursements selon le canal ; vérifier les justificatifs côté serveur.
• [ ] P1 Tester les notifications de paiement signées, les doublons et les événements reçus dans le désordre.
• [ ] P1 Faire valider les conditions d'essai, prix TTC, reconduction, résiliation, rétractation et médiation applicables au parcours réel. Supprimer les offres ou promesses non disponibles.
• [ ] P1 Vérifier les droits et licences des images de cartes, logos, catalogues et données de prix : usage commercial, redistribution, cache et obligations d'attribution. Une attribution seule ne vaut pas autorisation.
• [ ] P1 Évaluer les obligations d'accessibilité applicables au service et à l'entreprise avant commercialisation ; ne pas déduire leur absence du seul fait qu'il s'agit d'une application mobile.

Sources : Service Public : informations et conditions de vente, DGCCRF : rétractation, Apple : App Review Guidelines, Google Play : données utilisateur.

10. Exploitation, support et ouverture

• [ ] P1 Surveiller disponibilité, erreurs API, latences, stockage, sauvegardes, purges et dépenses externes ; faire un test de réception des alertes.
• [ ] P1 Disposer de journaux utiles mais expurgés des tokens, secrets, photos et collections privées ; limiter accès et conservation.
• [ ] P1 Vérifier santé/readiness des services sans exposer de détails sensibles au public.
• [ ] P1 Nommer la personne qui reçoit les alertes, celle qui décide du rollback et celle qui traite les demandes utilisateurs/RGPD.
• [ ] P1 Préparer les procédures panne, fuite de données, fournisseur indisponible, compte compromis et abus de scan.
• [ ] P1 Prévoir un contact support fonctionnel et la communication d'incident.
• [ ] P1 Faire une bêta contrôlée puis une ouverture progressive, avec surveillance renforcée et critères de suspension.
• [ ] P1 Ne pas effectuer de tests destructifs ou de charge sur la production sans accord explicite, périmètre et fenêtre définis.

11. Compléments importants ajoutés à notre première discussion

Les points suivants n'étaient pas assez détaillés dans la première liste :

1. Récupération de compte, changement d'appareil et révocation effective des sessions.
2. Compatibilité des anciennes applications mobiles avec les nouvelles API/migrations.
3. Confidentialité des exports et liens de partage, pas seulement des collections.
4. Protection de la chaîne CI, des comptes administrateurs et des secrets présents dans les bundles.
5. Limites des images décodées et destinations des téléchargements serveur.
6. Qualité de reconnaissance, variantes et gestion des identifications incertaines.
7. Cohérence des prix, valorisations incomplètes et dates de fraîcheur.
8. Vérification serveur des abonnements, remboursements et notifications de paiement.
9. Licences des visuels et données de fournisseurs, distinctes du RGPD.
10. Conservation des sauvegardes et suppression après restauration.
11. Accessibilité, support, responsabilités opérationnelles et lancement progressif.

12. Automatisations à mettre en place

Ces automatisations sont proposées, pas installées par ce document. Les cadences sont indicatives : elles doivent être adaptées aux objectifs de reprise, aux volumes et au budget. Pas de déploiement, migration, purge ou changement VPS sans validation du périmètre.

Automatisation	Déclenchement recommandé	Résultat attendu et garde-fou
Lint, types et tests unitaires	Chaque PR	Échec bloquant ; ne pas affaiblir les règles pour passer.
Tests d'intégration et isolation des comptes	PR backend concernée et avant promotion	Base de test isolée ; aucun accès aux données de production.
Audit dépendances, images et secrets	PR concernée et contrôle périodique, par exemple hebdomadaire	Alertes triées avec responsable et échéance ; pas de mise à jour majeure automatique non testée.
Build de production et tests de parcours	Avant chaque livraison	Artefact signé/identifié, contrat API compatible et preuve de test.
Déploiement et smoke tests	Après validation humaine des contrôles	Migration maîtrisée, contrôle après déploiement, seuil de suspension et reprise documentés.
Sauvegarde base et fichiers	Selon RPO ; une sauvegarde quotidienne ne couvre pas un objectif de perte inférieur à 24 h	Chiffrement, copie hors VPS, contrôle d'intégrité et alerte si sauvegarde absente. Évaluer sauvegardes incrémentales/journaux PostgreSQL si nécessaire.
Restauration de contrôle	Avant MEP puis périodiquement, par exemple mensuellement et après changement important	Environnement isolé, vérification fonctionnelle, durée mesurée, données protégées.
Purges RGPD et expirations	Selon les durées validées, généralement exécution quotidienne pour les données concernées	Simulation initiale, traitements idempotents et bornés, suivi des échecs et absence de chevauchement dangereux.
Suppression demandée par utilisateur	À la demande, avec reprise automatique bornée en cas d'échec	Suivi de bout en bout, nettoyage des données associées et procédure pour les sauvegardes.
Disponibilité externe API/vitrine	En continu, par exemple toutes les 1 à 5 minutes	Sonde hors VPS, échecs confirmés avant alerte, coût faible et données synthétiques.
Parcours synthétique scan/collection	Cadence limitée selon coût et besoin	Compte de test isolé, image de test autorisée, aucune collection réelle modifiée ; distinguer test technique et qualité de reconnaissance.
Expiration certificats et domaine	Contrôle périodique, par exemple quotidien	Alerte assez tôt pour agir ; vérification du renouvellement HTTPS réel.
Ressources, erreurs et coûts	Collecte continue	Alertes actionnables ; métriques bornées et sans informations privées inutiles.
Compte rendu de santé	Revue quotidienne/hebdomadaire adaptée à l'équipe	Incidents, budgets, fraîcheur des sauvegardes, purges et actions ouvertes. Ne remplace pas les alertes urgentes.

• [ ] P1 Chaque tâche a un propriétaire, une limite de durée, une preuve de réussite et une alerte d'absence/échec ; ne pas surveiller uniquement le code de sortie.
• [ ] P1 Les tâches planifiées reprennent après interruption et ne s'exécutent pas en double de façon dangereuse.
• [ ] P1 Les permissions sont limitées au besoin ; les secrets restent dans les mécanismes prévus, pas dans les scripts versionnés ou les rapports.
• [ ] P1 Les tests et tâches lourdes ne concurrencent pas les scans et écritures utilisateur sans limites de ressources.
• [ ] P1 Renouvellements, traitements et contrôles sont testés avec un échec volontaire en environnement isolé.

Ne pas automatiser aveuglément : reboot, mises à jour majeures, migrations destructrices, restauration de base, suppression de fichiers ou rollback incompatible avec les données. Les redémarrages automatiques doivent être bornés et signalés ; une boucle de redémarrage n'est pas une réparation.

13. SRE : objectifs, surveillance et fonctionnement dégradé

13.1. Définir ce que signifie "ça tourne bien"

Un fonctionnement fiable doit être mesurable côté utilisateur, pas seulement par un conteneur démarré. Aucun dispositif ne garantit zéro incident.

Parcours / risque	Indicateur à mesurer	Décision à prendre avant ouverture
Consulter et enregistrer une collection	Taux de réussite et latence des opérations attendues	Objectif de disponibilité, latence et règle de comptage des erreurs.
Scanner une carte	Latence de bout en bout, échecs techniques, précision sur corpus et résultats incertains	Objectifs distincts pour vitesse, disponibilité et qualité de reconnaissance.
Obtenir une valorisation	Réussite, part des cartes valorisées et âge des prix	Fraîcheur acceptable, affichage des valeurs partielles/périmées et coût maximal.
Reprendre après incident	Durée réelle de restauration et écritures potentiellement perdues	RTO et RPO acceptés par l'équipe.
Fournisseurs externes	Latence, erreurs, appels/minute et dépenses	Quotas, budget, seuil de coupure et comportement dégradé.

• [ ] P1 Définir des objectifs de service (SLO) réalistes, leur fenêtre de mesure et leurs exclusions justifiées ; ne pas exclure les erreurs serveur pour embellir le résultat.
• [ ] P1 Définir un budget d'erreur et une règle de suspension des livraisons lorsque la fiabilité se dégrade.
• [ ] P1 Ne pas confondre scan techniquement réussi et carte correctement identifiée.
• [ ] P1 Faire correspondre les engagements publics aux capacités réellement testées.

13.2. Tableau de bord minimal

• API : volume de requêtes, taux d'erreur, latence p50/p95/p99 et refus par quota.

• Scan : demandes, latence, file d'attente, tâches actives, saturation et échecs ; qualité contrôlée sur un corpus distinct.

• PostgreSQL : connexions utilisées, requêtes lentes, verrous, volume disque et erreurs.

• Redis : disponibilité, mémoire, évictions, taux de succès du cache et appels externes déclenchés.

• VPS/conteneurs : CPU, mémoire, OOM, espace disque/inodes, redémarrages et état des services.

• Fournisseurs : erreurs, délais, quotas, fraîcheur des données et dépenses.

• Sauvegardes/batchs : dernière réussite, durée, retard, nombre d'échecs et dernier test de restauration.

• Mobile : crashs et erreurs bloquantes du build de production, avec collecte minimisée et encadrée avant activation d'un SDK.

• [ ] P1 Ne pas utiliser identifiants utilisateurs, jetons ou chaque identifiant de carte comme labels de métriques sans nécessité ; contrôler confidentialité et cardinalité.

• [ ] P1 L'observabilité a elle-même une rétention et des limites de stockage, d'accès et de coûts.

• [ ] P1 Au moins une sonde et le canal d'alerte ne dépendent pas du VPS surveillé : une panne de ce VPS ne doit pas rendre le problème invisible.

13.3. Alertes et réponse

Une alerte urgente doit conduire à une action. Une anomalie non urgente devient une tâche de suivi, pas une notification permanente.

Situation	Réponse attendue
API/collection indisponible ou erreurs soutenues	Alerte urgente, responsable et procédure de diagnostic ; reprise ou rollback maîtrisé.
Scans ralentis, backlog ou saturation	Alerte selon impact ; réduire/admettre moins de travail, préserver les opérations de collection.
Disque proche de saturation	Alerte préventive fondée sur espace et vitesse de croissance ; pas de suppression automatique improvisée.
Sauvegarde trop ancienne ou restauration échouée	Alerte au responsable ; corriger avant une livraison risquée.
Fournisseur en erreur ou budget proche du plafond	Limiter les appels, utiliser les valeurs connues si approprié et afficher la dégradation.
Purge/suppression échouée	Reprise contrôlée et suivi jusqu'à résolution ; vérifier l'absence de perte hors périmètre.
Certificat proche de l'expiration ou accès suspect	Intervention selon urgence avec procédure adaptée.

• [ ] P1 Chaque alerte a un destinataire principal, un relais, une gravité, une procédure et un test de réception.
• [ ] P1 Définir les délais d'acquittement et la couverture réelle de l'équipe ; ne pas promettre une astreinte 24/7 inexistante.
• [ ] P1 Regrouper les alertes liées, réduire les faux positifs et surveiller les dégradations persistantes ; faire évoluer vers des alertes liées aux SLO lorsque les mesures sont fiables.
• [ ] P1 Après incident important : chronologie, impact, cause, correction et action de prévention, sans chercher un responsable à blâmer.

13.4. Isolation et modes dégradés

• [ ] P0 Une requête de scan ou un batch ne doit pas pouvoir épuiser sans limite toutes les ressources nécessaires aux collections.
• [ ] P1 Borner concurrence, files d'attente, pools DB et délais ; refuser proprement la surcharge plutôt que créer une file infinie.
• [ ] P1 Limiter les retries avec délai progressif et dispersion ; arrêter temporairement les appels à un fournisseur défaillant pour éviter les tempêtes de requêtes.
• [ ] P1 En cas de panne Redis, ne pas basculer chaque demande vers un appel externe payant illimité. Décider séparément du comportement des prix et des quotas si ces derniers utilisent Redis.
• [ ] P1 Une donnée périmée n'est servie que selon une règle explicite, avec fraîcheur visible ; ne jamais inventer un prix ou un 0 EUR pour masquer une panne.
• [ ] P1 Définir les boutons de coupure serveur : scan, appels de prix, fonctionnalité nouvelle. Leur accès est protégé et leur effet est testé.
• [ ] P1 Tester redémarrage avec écritures en cours, reprise de tâches et arrêt propre, sans doublons ni perte silencieuse.
• [ ] P1 Prévoir réserve CPU/RAM/disque et critères de montée en capacité avant saturation.

13.5. Socle proportionné à Snag

Commencer par sonde externe, métriques essentielles, journaux maîtrisés, sauvegardes/restaurations et alertes avec procédures. Réutiliser les outils déjà présents avant d'ajouter une nouvelle plateforme d'observabilité. Kubernetes ou une architecture multi-région ne sont pas un prérequis de fiabilité.

Un VPS unique reste un point de panne unique. Une copie hors VPS et une reprise testée réduisent l'impact, mais ne constituent pas de la haute disponibilité. Si les objectifs acceptés exigent de continuer pendant une panne du VPS, prévoir une architecture redondante et tester son basculement.

Sources : Google SRE : surveillance des systèmes, Google SRE : alertes liées aux objectifs de service. Les choix de cadences, outils et architecture ci-dessus sont des recommandations pour Snag, pas des obligations imposées par ces sources.

14. Décision de lancement

Ordre recommandé : isolation des comptes > exposition réseau et secrets > restauration > anti-abus et coûts > RGPD effectif > parcours de production > exploitation.

Ne pas ouvrir la production avec :

• une fuite ou une modification possible des données d'un autre utilisateur ;
• une base, Redis ou une interface administrative exposée sans protection adaptée ;
• un secret de production compromis ou une vulnérabilité critique exploitable non traitée ;
• une restauration non testée ou une migration sans stratégie de reprise ;
• des opérations coûteuses sans limites effectives ;
• une perte de collection reproductible ;
• des traitements soumis à consentement activés sans accord, ou un parcours de suppression non conforme aux exigences applicables ;
• une offre payante active sans contrôle fiable des droits et parcours contractuel validé.

Une attestation mobile ou une obfuscation non encore déployée ne constitue pas automatiquement un blocage si les protections essentielles sont validées et le risque documenté. Inversement, leur présence ne rend pas le backend sûr par elle-même.

Tableau de suivi minimal

Domaine	Responsable	Version / date	Preuve	Résultat / action
API et isolation des comptes	À définir	À renseigner	À joindre	À vérifier
Réseau, VPS et dépendances	À définir	À renseigner	À joindre	À vérifier
Sauvegarde, migration et reprise	À définir	À renseigner	À joindre	À vérifier
Anti-abus, charge et coûts	À définir	À renseigner	À joindre	À vérifier
RGPD, documents et purges	À définir	À renseigner	À joindre	À vérifier
Parcours métier et builds	À définir	À renseigner	À joindre	À vérifier
Paiement et licences si applicables	À définir	À renseigner	À joindre	À vérifier
Alertes, support et décision de lancement	À définir	À renseigner	À joindre	À vérifier
Automatisations, objectifs SRE et modes dégradés	À définir	À renseigner	À joindre	À vérifier

État actuel de cette checklist : validations non renseignées. Les sujets manquants dans la discussion sont identifiés ci-dessus ; les travaux réellement manquants dans Snag ne pourront être confirmés qu'après inspection et tests du périmètre déployé.