Liste noire et verification licence

Protocole de vérification

Un opérateur n’est positivement vérifié que lorsque cinq champs concordent

Le contrôle ne cherche ni joli logo ni simple mention de licence. Il compare domaine consommateur exact, classe belge pertinente, numéro de dossier, titulaire juridique et validité à une date précise. Pour A+, B+ et F1+, il conserve aussi le lien avec la licence de base. Si un champ essentiel manque ou diverge, le résultat n’est pas verified. C’est plus strict que « absent de la blacklist », car aucune liste négative ne couvre tous les nouveaux sites.

Workflow : de l’URL collée au reçu de preuve

1. Figer l’entrée. Conservez localement l’URL saisie, retirez le tracking et ne demandez ni login, mot de passe, jeton ou paiement. Si seule une marque est fournie, tous les domaines trouvés restent candidats, pas sites officiels prouvés.
2. Normaliser le hostname. Passez en minuscules, retirez point final et port standard, affichez IDN/punycode, notez relation www/apex. Ne supprimez jamais un sous-domaine significatif comme account, play ou casino, qui peut mener à une autre partie.
3. Suivre les redirections. Enregistrez codes, chaque hostname et URL finale sans ouvrir de compte. Arrêtez en cas de téléchargement, alerte certificat, boucle ou géo inattendue. Un saut affilié est étiqueté séparément et ne prouve aucune licence.
4. Déterminer produit et classe attendue. Casino/table, arcade et paris exigent des recherches typées différentes. A+, B+ et F1+ ne sont pas interchangeables ; la Loterie Nationale ne rejoint pas cette chaîne sans source.
5. Chercher la preuve réglementaire positive. Cherchez domaine exact, dossier et titulaire dans la table actuelle. Conservez date du snapshot, URL, décision, échéance et publication. Un cache de moteur n’est qu’une aide de navigation.
6. Recouper l’allégation du site. Comparez footer/licence, conditions, entité privacy et bénéficiaire du paiement avec la ligne officielle. Une différence de société ou domaine ne devient pas « white label » sans relation prouvée.
7. Contrôler séparément les sources négatives. Cherchez blacklist, décisions de blocage et avertissements. Une licence positive et une action négative sur le même objet/période produisent un conflit, pas un vert ou rouge automatique.
8. Rendre un résultat délimité. Affichez verified-for-class, mismatch, expired, blacklisted, not-found, conflict ou source-unavailable avec date. Citez domaine et classe examinés. Jamais « 100 % sûr » ou « fiable » comme conclusion juridique.

Pondérer les signaux : l’enregistrement positif ne corrige pas une identité divergente

Exemples de résultats sans simuler de vraies marques

Ce que signifie réellement « not found »

Not-found signifie que les variantes normalisées n’ont pas produit de match positif dans la source et le snapshot cités. Cela peut signaler un site illégal, mais aussi faute, nouveau domaine, alias, mauvaise classe, source incomplète ou panne. L’utilisateur ne reçoit ni voie verte ni accusation pénale infondée. Le checker montre variantes, sources, date et méthode pour ouvrir lui-même la source officielle.

Si argent ou identité ont déjà été partagés, la suite devient limitation du dommage : arrêter paiements, contacter banque/carte via un numéro trouvé indépendamment, changer les mots de passe réutilisés, conserver URL/transactions et signaler la fraude. Ne payez aucun recovery service promettant spontanément un remboursement.

Reçu de preuve : rendre le contrôle reproductible

• URL saisie et hostname normalisé, sans paramètres secrets.
• Chaîne de redirection et hôte final avec heure, sans création de compte.
• Catégorie produit attendue et classe(s) recherchée(s).
• Source officielle exacte, date, dossier, titulaire et validité.
• Allégation footer/conditions avec URL et horodatage, uniquement en recoupement secondaire.
• Contrôle blacklist/blocage avec version ; absence jamais formulée comme whitelist.
• Code résultat, motif d’incertitude, date et échéance de recontrôle.

Confidentialité et sécurité du vérificateur

Le vérificateur n’a besoin ni de compte, eID, nom complet, téléphone, banque ou document. Il contrôle des données publiques d’entité et domaine. Les URL avec jetons, e-mails ou sessions sont nettoyées avant journalisation ; l’entrée n’est pas renvoyée vers un domaine inconnu. Les fetches utilisent délais, limite de redirections, protocoles autorisés et protection contre adresses locales/privées. Le HTML externe n’est jamais injecté comme code fiable.

Quand recommencer le contrôle

Recontrôlez avant inscription ou paiement, lors d’un changement de domaine/marque, nouvelles conditions, redirection vers autre hôte, mise à jour du régulateur, contrôle périmé ou plainte d’usurpation. Un reçu antérieur ne couvre que hostname, classe et moment examinés. Il n’est pas une approbation transférable aux sites frères, apps, mirrors ou campagnes futures.

Diagnostic de six cas difficiles

1. Domaine Unicode ou ressemblant

Affichez forme lisible et ASCII/punycode, puis comparez caractère par caractère. Une lettre cyrillique, un tiret ou ordre différent peut cacher un clone. Ouvrez le domaine officiel depuis le registre, jamais depuis la page suspecte, et ne copiez aucun login ou document.

2. White-label ou plateforme partagée

Un logiciel ou support commun ne prouve pas une licence partagée. Cherchez le contractant dans conditions/privacy, le bénéficiaire du paiement et le domaine exact au registre. Seule une relation prouvée est conservée ; « powered by » ou interface identique n’est pas un match titulaire.

3. Application sans domaine visible

Une fiche d’app est une métadonnée de distribution, pas une preuve réglementaire. Identifiez développeur, domaines support/privacy, hôtes publics et entité des conditions. Faites ensuite correspondre domaine consommateur et classe ; n’installez pas uniquement pour chercher la licence.

4. Un domaine cite plusieurs produits

Séparez casino/arcade et paris. Pour chaque produit, notez classe attendue, titulaire et ligne. Un match F1+ ne légalise pas automatiquement le casino ; un match A+/B+ ne couvre pas automatiquement les paris.

5. Source officielle temporairement indisponible

Rendez source-unavailable avec heure et éventuellement le dernier snapshot comme contexte historique. Ne remplacez pas silencieusement par une copie affiliée. Planifiez retry, mirror ou téléchargement officiel, et gardez tout CTA désactivé.

6. Titulaire modifié après acquisition

Une annonce d’acquisition ne prouve pas la date du transfert de licence. Conservez anciens et nouveaux titulaires comme périodes, cherchez la décision et vérifiez dossier/domaine. Ne mélangez pas avis, plaintes ou incidents de deux périodes juridiques sans date.

Format de sortie lisible pour l’utilisateur et l’audit

En tête figurent réponse directe avec couleur et texte, objet contrôlé et date. Une table compacte montre domaine, classe, dossier, titulaire, base, décision et échéance sans cacher les vides. La preuve lie la source primaire et sa date. Une section incertitude cite les champs manquants ou contradictoires. La suite dépend du résultat : verified mène aux conditions et à la prévention ; mismatch/not-found à l’arrêt et nouveau contrôle ; blacklisted à la limitation du dommage ; conflict/source-unavailable à l’attente de vérification.

Le reçu téléchargeable ne contient ni marketing, étoiles, bonus ou badge « trusted ». Il porte un identifiant, version de méthode, hash de source si disponible et avertissement que les données peuvent changer après la date. Utilisateur, rédacteur ou auditeur peut ainsi reconstruire le résultat et identifier la nouvelle preuve nécessaire pour le modifier.

Un second contrôleur examine tout cas commercial avant publication et valide seulement les champs réellement vus dans la source primaire. L’automatisation peut classer des candidats, mais ne publie jamais seule un opérateur : ponctuation, formes juridiques, alias de domaine et dossiers expirés créent des faux positifs dangereux. Toute dérogation manuelle journalise motif, auteur, heure et expiration ; sans nouvelle source, elle ne peut jamais produire verified-for-class. Les contrôles d’accès empêchent aussi qu’un partenaire modifie directement le statut ou masque une contradiction.