Blog

J’ai décidé de faire ce projet pour me remettre en mode programmeur pendant le congé des Fêtes. Coder pour vrai, c’est à dire sans manger, dormir, savoir quel jour nous sommes rendu ou prendre ma douche!, J’ai beaucoup d’admiration pour ceux qui en font leur métier. 

Cela dit, je vous présente le résultat l’outil: loi25.certi360.com

Il est difficile d’avoir un portrait complet d’un site web en terme de conformité à la loi 25, sur la protection des renseignements personnel dans le secteur privé, c’est pourquoi j’ai essayé d’automatiser le processus. 

Il faut savoir que la loi demande que le minimum raisonnable soit fait pour protéger la collecte des renseignements personnels et qu’il y ai un consentement à la collecte. 

Attention: L’outil n’est surtout pas un avis juridique, il comporte des bugs et ne détecte pas toujours correctement certains items. 

Ce que fait l’outil

l’outil analyse ce qui est observable sur un site web. L’outil est construit sur cinq blocs de tests avec Seize modules de vérification. 

Analyse du domaine et de la configuration courriel Ce bloc examine ce que le nom de domaine révèle publiquement. Hébergement. Informations WHOIS. Configuration DNS. Paramètres de messagerie.

Il permet notamment d’identifier où le site est hébergé, si des indices de transferts hors Québec ou hors Canada sont visibles, et si la configuration courriel expose des faiblesses évidentes. Le résultat produit une vue technique factuelle. Pas une conclusion légale.

Analyse du chiffrement TLS Ce bloc vérifie comment les communications sont protégées entre le navigateur et le site. Certificat TLS. Protocoles utilisés. Configurations faibles ou obsolètes.

Il produit une évaluation claire de la robustesse du chiffrement observable. C’est un indicateur direct du sérieux accordé à la protection des données en transit.

Analyse des en-têtes de sécurité et des technologies exposées Ce bloc inspecte les en-têtes HTTP de sécurité et les technologies détectables publiquement.

Il met en évidence l’absence ou la présence de mécanismes de protection contre des attaques courantes. Il identifie aussi certaines technologies utilisées afin de contextualiser les risques visibles.

Analyse des cookies et du consentement Ce bloc observe l’utilisation des cookies sur le site. Présence de cookies. Cookies tiers. Fonctionnement de la bannière de consentement.

Il vérifie si la navigation est possible sans accepter les cookies non essentiels. Il met en lumière les incohérences visibles entre discours et comportement réel du site.

Analyse de la politique de confidentialité Ce bloc tente de localiser automatiquement la politique de confidentialité. Puis d’en analyser le contenu.

L’analyse vérifie la présence des éléments attendus par la Loi 25. Collecte. Utilisation. Droits des personnes. Partage avec des tiers. Transferts. Conservation. Responsable.

Tester votre site

L’outil est gratuit. Sans inscription.

Vous entrez un nom de domaine. Vous lancez l’analyse. En quelques minutes, vous voyez ce que votre site raconte.

https://loi25.certi360.com

Testez-le. Regardez les résultats. Et surtout, prenez le temps de comprendre.

 

ISO 19011 a été publiée en mai 2026. Si vous avez lu mon article sur la version 2018, ici je vous parle de la nouvelle version.

La structure reste la même : principes d’audit, programme d’audit, réalisation, compétence des auditeurs. Ce qui change, c’est le contenu à l’intérieur de ces chapitres.

Les audits à distance sont maintenant une méthode normale

La version 2026 définit formellement la notion d’audit à distance à la clause 3.4 : une méthode utilisée pour conduire des activités d’audit depuis tout endroit autre que les locaux de l’audité. L’ajout dans les définitions, c’est le signal que ce n’est plus une option de secours.

La clause 5.1 va plus loin : le programme d’audit doit maintenant documenter les méthodes d’audit à utiliser, y compris les méthodes d’audit à distance (item g). Ce n’est plus implicite, c’est une exigence du programme.

La clause 3.6 précise aussi que la portée d’un audit inclut désormais les emplacements physiques et virtuels. Un environnement infonuagique ou une plateforme numérique sont des sites auditables.

L’annexe A.16 encadre la conduite concrète des audits à distance. Elle couvre :

• La préparation technique : vérification des accès, protocoles convenus, plans de contingence en cas de panne.
• La sécurité des données et la confidentialité, y compris la gestion des pauses (mettre en sourdine, couper la caméra).
• La demande de permission avant toute capture d’écran ou enregistrement.
• La compétence spécifique requise : l’auditeur doit maîtriser les outils technologiques utilisés et savoir conduire un audit à distance efficacement.

L’annexe A.17 ajoute une précision sur les entretiens à distance (clause g) : dans un contexte virtuel, la communication non verbale est limitée. L’auditeur doit adapter le type de questions pour obtenir des preuves objectives.

Pour les détails opérationnels complets, la norme renvoie à ISO/IEC TS 17012:2024.

Le programme d’audit doit gérer ses propres risques

La clause 4.8 établit l’approche fondée sur les risques comme principe fondamental. La clause 5.3 l’applique directement au programme d’audit lui-même.

Les risques à évaluer incluent notamment :

• La sélection de la méthode d’audit : sur site, à distance, en tenant compte de la capacité de la méthode choisie à atteindre l’objectif d’audit (clause 5.3 d).
• La sécurité des méthodes TIC utilisées : plateformes non sécurisées, sélection inadéquate des outils (clause 5.3 k).
• La coordination et la confidentialité dans la mise en œuvre (clause 5.3 f).

Le programme doit documenter ces risques et les actions pour les adresser. La clause 5.1 b) est explicite : le programme doit inclure les risques et opportunités associés au programme d’audit (voir 5.3) et les actions pour y répondre.

Les audits combiné de plusieurs normes ont leurs propres exigences de compétence

La clause 7.2.3.5 introduit des exigences spécifiques pour les audits couvrant plusieurs disciplines. Le membre de l’équipe d’audit doit comprendre les interactions et les synergies entre les différents systèmes de gestion.

Le chef d’équipe, lui, doit comprendre les exigences de chaque norme auditée et reconnaître les limites de sa propre compétence dans chaque discipline.

L’annexe A.13 précise comment préparer les documents de travail pour les audits combinés : regrouper les exigences similaires de différents critères et coordonner les listes de vérification pour éviter les doublons.

L’annexe A.18.4 aborde les constats liés à plusieurs critères. Lorsqu’un constat touche plusieurs normes, l’auditeur peut soit émettre des constats séparés pour chaque critère, soit un constat unique qui regroupe les références aux différents systèmes. C’est un accord avec le client d’audit qui détermine l’approche.

La compétence des auditeurs intègre la technologie et la pensée critique

La clause 7.2.3.2 a) liste les connaissances et compétences génériques requises. Le point 10 est nouveau et concret :

L’auditeur doit comprendre l’opportunité et les conséquences de l’utilisation des TIC et des technologies émergentes pour conduire les audits, y compris les outils d’évaluation basés sur l’intelligence artificielle.

C’est la première fois que l’IA est mentionnée explicitement dans la norme.

Le point 4 réitère l’exigence de prioriser et de se concentrer sur les sujets significatifs. C’est la pensée critique appliquée : ne pas couvrir toutes les clauses de façon égale, mais concentrer l’effort là où le risque est plus élevé.

La clause 7.6 encadre le développement professionnel continu. Il doit tenir compte notamment des développements dans la pratique d’audit, y compris l’utilisation de la technologie (clause 7.6 b).

La santé et la sécurité des auditeurs sont formalisées

La clause 7.2.3.4 d) 3) précise que le chef d’équipe doit tenir compte de la santé et de la sécurité des membres de l’équipe d’audit, y compris en s’assurant que les dispositions pertinentes en matière de santé, sécurité et sûreté sont respectées.

L’annexe A.15 détaille ce que ça implique en pratique pour les visites sur site :

Obtenir les informations sur la sécurité, la santé (vaccinations recommandées, quarantaine), les normes culturelles et les heures de travail.

• Confirmer la disponibilité des équipements de protection individuelle (EPI) requis.
• Communiquer les procédures d’urgence : sorties de secours, points de rassemblement.
• Ne pas toucher ni manipuler d’équipements, sauf permission explicite.

Ce n’est pas nouveau dans la pratique. C’est nouveau dans le texte normatif.

Sources

Le texte cité dans cet article est tiré directement d’ISO 19011:2026. La norme est disponible auprès de l’ISO à l’adresse iso.org/standard/19011. Elle est sous droit d’auteur. J’ai inclus l’information afin de vous pointer aux bons endroits dans la norme.

On reçoit tous des courriels avec des liens. Parfois on est certains que c’est valide basé sur la confiance d’autre fois on doute. Et ce doute est sain, parce que les liens malveillants sont aujourd’hui la première porte d’entrée des attaque.

Voici comment vérifier un lien avant de cliquer, selon ce qu’on cherche à détecter.

Étape 0 : regarder le lien sans cliquer

Avant tout outil, la première défense est visuelle.

Sur ordinateur : passez la souris sur le lien sans cliquer. L’URL réelle s’affiche en bas à gauche de votre navigateur ou dans votre client courriel. Ce que vous lisez dans le texte du courriel (“Cliquez ici” ou “www.votre-banque.com ») peut être entièrement différent de l’URL réelle.

Ce qu’il faut vérifier à l’oeil :

• Le domaine de base : votre-banque.com est très différent de votre-banque.connexion-securisee.xyz. Le vrai domaine, c’est ce qui précède immédiatement le .com, .ca, .net, etc.
• Le typosquatting : paypa1.com (avec un 1), rbc-canada.net, microsoft-support.com. Des variations subtiles conçues pour tromper l’oeil.
• Les liens raccourcis (bit.ly, tinyurl, t.co) : ils cachent la destination réelle. Ne cliquez jamais dessus sans avoir déplié l’URL d’abord.

Pour dépiler un lien raccourci sans cliquer : unshorten.it ou expandurl.net Collez l’URL courte, et vous voyez la destination réelle.

Pour détecter les malwares et les virus : VirusTotal

VirusTotal.com analyse l’URL avec 90+ moteurs antivirus simultanément. Si le lien mène vers un fichier malveillant ou un site connu pour distribuer des logiciels malveillants, vous le saurez en 10 secondes.

Utilisation : copiez l’URL, collez-la dans VirusTotal, lancez l’analyse. Un résultat “0/90” (aucun moteur ne détecte rien) est rassurant, mais pas une garantie absolue pour le phishing, c’est la limite de cet outil. 

Pour détecter le phishing : les bons outils

Le phishing, c’est une fausse page qui imite une vraie (votre banque, Microsoft, le gouvernement, Poste Canada) pour voler vos identifiants ou vos informations personnelles. Aucun virus, aucun logiciel malveillant, juste une interface convaincante et un formulaire qui envoie vos données aux attaquants.

Voici les outils spécialisés :

1. URLScan.io — le plus puissant

urlscan.io

C’est l’outil le plus utile de cette liste. URLScan visite le lien dans un environnement isolé (sandbox), fait une capture d’écran de la page, analyse le code, les ressources chargées, les redirections, et vous donne un rapport complet.

Vous pouvez voir visuellement à quoi ressemble la page sans jamais y aller. Si le site imite votre banque, vous le verrez immédiatement. Si la page redirige vers autre chose, vous le saurez.

Attention : par défaut, les scans sont publics. Si vous analysez un lien sensible d’un courriel interne d’entreprise, utilisez un scan privé (nécessite un compte gratuit).

2. Google Safe Browsing — rapide et fiable

transparencyreport.google.com/safe-browsing/search

Google maintient une liste noire des sites de phishing et de malware mise à jour en continu. Collez l’URL, et Google vous dit si elle est signalée. Simple, rapide, efficace pour les sites déjà connus.

C’est d’ailleurs ce que votre navigateur (Chrome, Firefox, Safari) vérifie automatiquement à chaque page visitée. Mais vous pouvez le faire manuellement avant de cliquer.

3. PhishTank — la base communautaire du phishing

phishtank.org

PhishTank est une base de données collaborative : des milliers de bénévoles soumettent et vérifient des URLs de phishing. Si quelqu’un d’autre a déjà reçu le même lien douteux, il est probablement ici.

Très utile pour les campagnes de phishing à grand volume (faux courriels de Postes Canada, de l’ARC, des banques), moins utile pour les attaques ciblées récentes.

4. CheckPhish.ai — l’IA appliquée au phishing

checkphish.ai

Un outil plus récent qui utilise l’intelligence artificielle pour détecter les pages de phishing, même inconnues. Il analyse la structure visuelle et le contenu de la page pour déterminer si elle imite une marque connue. Bon complément à URLScan pour les sites très récents.

---

La méthode en pratique : 60 secondes, 3 étapes

1. Regardez l’URL sans cliquer. Le domaine de base a-t-il du sens? Est-ce que vous reconnaissiez vraiment l’expéditeur?
2. Collez l’URL dans URLScan.io. Regardez la capture d’écran. Est-ce que la page ressemble à ce qu’on vous promet? Y a-t-il des redirections suspectes?
3. Si le doute persiste, passez-la aussi dans VirusTotal et Google Safe Browsing.

---

Ce qu’aucun outil ne remplacera

La règle d’or qui survit à toutes les technologies :

Si on vous demande vos identifiants, votre mot de passe, votre numéro de carte ou des informations personnelles via un lien reçu par courriel — n’allez pas sur ce lien. Allez directement sur le site officiel en tapant l’adresse vous-même.

Votre banque ne vous enverra jamais un lien en vous demandant de “valider votre compte dans les 24 heures”. L’ARC n’envoie pas de courriels avec des liens cliquables. Ces manières de faire sont des signaux d’alarme, peu importe à quel point le courriel semble légitime.

Votre meilleure protection est de rester septique !

Je ne peux pas m’empêcher de citer un de mes livres et films préférés, mais dans ce cas, la référence n’est pas inutile. 

Une norme pour les gouverner tous, c’est exactement ce qu’est ISO 19011.

Si vous avez déjà reçu un rapport d’audit de conformité, ISO 27001, ISO 9001, ISO 22301, ce rapport obéi à une logique précise. 

La norme ISO 19011 encadre la façon d’auditer et la façon de documenter ce qui a été audité. C’est elle qui dicte comment un audit se planifie, se conduit et se conclut dans un rapport.

Pourtant, ISO 19011 est presque invisible dans les conversations sur la conformité. On parle de la norme auditée, ISO 27001, ISO 27701, ISO 42001 etc. Mais rarement de la norme qui encadre comment on audite. 

Comprendre ISO 19011, c’est comprendre ce que l’auditeur est censé faire, comment il doit le documenter et ce que votre organisation peut légitimement exiger de lui.

ISO 19011:2018 — Lignes directrices pour l’audit des systèmes de management.

C’est une norme générique qui s’applique à tous les audits de systèmes de management, quelle que soit la norme auditée. Elle définit comment les auditer.

Elle couvre quatre grandes questions :

1. Quels sont les principes qui gouvernent l’audit ?
2. Comment planifier et gérer un programme d’audit ?
3. Comment conduire un audit individuel, de la préparation au rapport final ?
4. Quelles compétences doit posséder un auditeur ?

ISO 19011 s’applique autant aux audits internes qu’aux audits externes de première, deuxième et troisième partie. Elle est la référence de compétence pour les auditeurs ISO 27001 et c’est la raison pour laquelle les organismes de certification accrédités comme Bureau Veritas, BSI et SGS forment leurs auditeurs sur cette base.

Les 7 principes fondamentaux de l’audit selon ISO 19011

ISO 19011 pose sept principes qui ne sont pas des suggestions. Ce sont les fondements sur lesquels repose la crédibilité de tout rapport d’audit.

1. Intégrité

L’auditeur agit avec honnêteté et responsabilité. Il rapporte ce qu’il constate, pas ce que le client veut entendre. Un auditeur qui minimise des non-conformités pour éviter un conflit viole ce principe.

2. Présentation impartiale

Les constats, conclusions et rapports doivent refléter fidèlement les activités d’audit. Aucun biais, aucune sélection favorable des preuves. Ce principe est directement lié à l’obligation de fonder les constats sur des preuves objectives.

3. Conscience professionnelle

L’auditeur applique son jugement professionnel tout au long de l’audit. Cela signifie qu’il adapte la profondeur de sa vérification au profil de risque de l’organisation, pas qu’il applique un gabarit identique à chaque client.

4. Confidentialité

Les informations obtenues durant l’audit sont protégées. L’auditeur ne divulgue pas à des tiers ce qu’il a vu dans vos systèmes, sauf obligation légale ou consentement explicite.

5. Indépendance

L’auditeur doit être libre de toute influence qui pourrait biaiser ses conclusions. C’est pourquoi un consultant qui vous a aidé à implanter votre SGSI ne devrait pas ensuite l’auditer lui-même. Ce conflit d’intérêts est une violation directe d’ISO 19011.

6. Approche fondée sur les preuves

C’est le principe le plus opérationnel. Les constats d’audit doivent être basés sur des preuves vérifiables. Une opinion, une impression, une intuition, ce n’est pas un constat d’audit. Si un auditeur vous remet une non-conformité sans la lier à une preuve objective, il déroge à ce principe.

7. Approche fondée sur les risques

La planification et la conduite de l’audit doivent tenir compte des risques liés aux objectifs de l’audit. En pratique : l’auditeur ne passe pas autant de temps sur un contrôle de faible criticité que sur un contrôle qui protège des données sensibles. L’allocation de l’effort d’audit doit être proportionnelle au risque.

Le parcours de vérification: comment ISO 19011 structure un audit

ISO 19011 décrit un cycle en cinq étapes. C’est ce que j’appelle le parcours de vérification, la logique séquentielle que suit tout audit bien conduit.

Étape 1 : Établissement du programme d’audit

Avant même de planifier un audit individuel, ISO 19011 demande qu’un programme d’audit soit établi. Ce programme définit la portée, la fréquence, les méthodes et les ressources pour l’ensemble des audits prévus sur une période donnée.

Pour une organisation certifiée ISO 27001, ça veux dire un calendrier annuel d’audits internes couvrant l’ensemble du SGSI, pas un audit ponctuel déclenché quand quelqu’un a le temps.

Ce que ça révèle : une organisation sans programme d’audit structuré signale immédiatement une maturité insuffisante sur la Clause 9.2 de l’ISO 27001.

Étape 2 : Planification de l’audit

Chaque audit individuel commence par une planification documentée. Elle précise les objectifs, les critères, le périmètre, les méthodes, les personnes à rencontrer, les documents à examiner et le calendrier.

ISO 19011 exige que cette planification soit communiquée à l’audité avant l’audit. Ce n’est pas une formalité, c’est une obligation qui permet à l’organisation de préparer les preuves pertinentes et de désigner les bons interlocuteurs.

Ce que ça révèle : un auditeur qui débarque sans plan documenté ne respecte pas ISO 19011. Vous avez le droit de le demander.

Étape 3 : Réalisation de l’audit

C’est la phase d’exécution. Elle comprend la réunion d’ouverture, la collecte de preuves (entretiens, observation directe, examen de documents), l’analyse des constats et la réunion de clôture.

ISO 19011 insiste sur un point souvent négligé : la réunion de clôture. L’auditeur doit présenter ses constats à l’audité avant de finaliser le rapport. Cela permet de corriger des malentendus factuels, pas de négocier les non-conformités, mais de s’assurer que les faits sont exactement représentés.

Si vous recevez un rapport avec des constats que vous n’aviez jamais entendus en réunion de clôture, il y a un problème de processus chez l’auditeur.

Étape 4 : Production du rapport d’audit

Le rapport doit être produit dans un délai convenu après l’audit. ISO 19011 en définit le contenu minimal : objectifs, périmètre, dates, identification de l’auditeur, identification de l’audité, constats avec base normative et preuves, conclusions et recommandations.

Un rapport qui ne contient pas ces éléments est un rapport incomplet, indépendamment de la qualité du travail sur le terrain.

Étape 5 : Clôture et suivi

L’audit n’est pas terminé quand le rapport est remis. ISO 19011 prévoit un suivi des actions correctives pour les non-conformités identifiées. L’organisation doit démontrer que les corrections ont été apportées et l’auditeur (ou son mandant) devrait en vérifier l’efficacité.

Les compétences exigées d’un auditeur

ISO 19011 consacre une section entière aux compétences requises pour les auditeurs. C’est ce qui distingue un auditeur qualifié d’un consultant qui remplit un gabarit.

Les compétences couvrent quatre items:

Connaissances de la norme auditée : un auditeur ISO 27001 doit maîtriser les 93 contrôles de l’Annexe A, les Clauses 4 à 10 et leur interprétation en contexte opérationnel.

Connaissances en audit : techniques d’entretien, collecte de preuves, rédaction de constats, gestion des conflits d’intérêts.

Connaissances du secteur d’activité : un auditeur qui ne comprend pas le contexte opérationnel de l’organisation ne peut pas évaluer la pertinence des contrôles.

Compétences personnelles : rigueur, objectivité, capacité à communiquer des constats difficiles sans ambiguïté.

ISO 19011 ne dit pas qu’un auditeur doit détenir telle certification. Elle dit qu’il doit démontrer ces compétences. La certification (CISA, ISO 27001 Lead Auditor) est un indicateur, pas une garantie.

Ce que vous pouvez exiger de votre auditeur

Si vous retenez une chose de cet article, que ce soit celle-ci : ISO 19011 vous donne des droits en tant qu’audité.

Vous pouvez exiger :

• Un plan d’audit documenté avant le début des travaux.
• Que chaque constat soit lié à une preuve objective et à une clause ou un contrôle précis.
• Une réunion de clôture avant la finalisation du rapport.
• Un rapport remis dans le délai convenu, avec le contenu minimal défini par la norme.
• Un suivi documenté des actions correctives.

Un auditeur qui refuse ces demandes ne respecte pas ISO 19011. Et un rapport produit sans respecter ces étapes est un rapport dont vous êtes en droit de contester la rigueur.

Bref, ISO 19011 n’est pas une norme optionnelle pour ceux qui aiment lire des normes. C’est le cadre qui gouverne la crédibilité de tout audit de système de management. 

Donc, quand vous recevez un rapport d’audit ISO 27001, vous savez comment l’évaluer pour savoir s’il est bon ou mauvais!

Aujourd’hui je vous présente les améliorations à l’outils https://loi25.certi360.com

Chaque test vise à vérifier un aspect du comportement du site vis-à-vis des cookies et du consentement.

---

1. CONFORMITÉ AU CONSENTEMENT

• Présence d’une bannière de consentement
  Vérification qu’une bannière ou un bandeau de gestion des cookies est affiché
  lors de la première visite. Le test détecte les solutions connues (Complianz,
  OneTrust, Axeptio, Cookiebot, Tarteaucitron, etc.) ou repère des éléments
  génériques (modales, boutons d’acceptation).
• Accessibilité du bouton « Refuser tout »
  Contrôle qu’un bouton permettant de refuser tous les cookies non essentiels
  est présent et cliquable. Si la bannière propose un bouton « Personnaliser »,
  le test cherche également un bouton de refus dans le panneau de préférences.
• Absence de cookies non essentiels après refus
  Après un clic sur « Refuser tout », comparaison des cookies présents avant et
  après. Tout cookie nouvellement créé ou modifié est classé (essentiel,
  non essentiel ou inconnu). Seuls les cookies non essentiels et inconnus
  ajoutés ou modifiés après le refus sont considérés comme des manquements.
• Classification des cookies (whitelist / blacklist)
  Chaque cookie est rattaché à une liste de patterns connus : cookies essentiels
  (session, CSRF, préférences de langue, gestion du consentement, etc.) ou
  non essentiels (analytics, publicité, réseaux sociaux). Les cookies non
  reconnus sont traités par défaut comme soumis au consentement.

---

2. SÉCURITÉ DES COOKIES

• Attributs HttpOnly sur les cookies sensibles
  Vérification que les cookies liés à la session, à l’authentification ou aux
  jetons (CSRF, JWT, etc.) portent l’attribut HttpOnly afin de limiter les
  risques d’exfiltration par script (XSS).
• Attribut Secure sur les sites en HTTPS
  Contrôle que les cookies de session ou d’authentification sont marqués
  « Secure » lorsque le site est servi en HTTPS, pour éviter la transmission
  en clair sur des canaux non sécurisés.
• Cohérence SameSite / Secure
  Détection des cookies avec SameSite=None qui ne portent pas l’attribut
  Secure, configuration rejetée par les navigateurs récents.

---

3. DURÉES DE CONSERVATION

• Durée de vie des cookies non essentiels
  Vérification que la date d’expiration des cookies non essentiels ou inconnus
  ne dépasse pas 13 mois (recommandation CNIL / article 82 RGPD).
• Durée de vie des cookies essentiels
  Contrôle que les cookies considérés comme strictement nécessaires n’ont pas
  une durée de conservation excessive (recommandation : 12 mois au plus).

---

4. DARK PATTERNS DANS LA BANNIÈRE

• Équilibre de visibilité entre « Accepter » et « Refuser »
  Analyse des tailles et des styles des boutons d’acceptation et de refus.
  Un bouton « Accepter » nettement plus grand ou plus mis en avant que
  « Refuser » est signalé comme potentiel dark pattern.
• Visibilité du bouton de refus
  Vérification que le bouton de refus n’est pas caché (display: none,
  visibility: hidden, opacité nulle) ou rendu inaccessible.
• Options pré-cochées
  Détection des cases à cocher déjà cochées par défaut pour des catégories
  non essentielles (analytics, publicité, etc.), ce qui va à l’encontre
  du principe du consentement explicite (opt-in).

---

5. TRANSPARENCE ET INFORMATION

• Présence d’un lien vers la politique de cookies
  Recherche sur la page d’un lien explicite vers la politique de gestion des
  cookies ou la politique de confidentialité (par libellé ou URL).
• Accessibilité du lien depuis la bannière
  Vérification que ce lien est proposé directement depuis la bannière de
  consentement, pour faciliter l’information de l’utilisateur avant son choix.

---

6. VALIDATION GOOGLE CONSENT MODE v2

• Détection de l’utilisation de Consent Mode
  Identification des sites qui utilisent Google Consent Mode v2 (dataLayer,
  commandes consent, gtag).
• Conformité des états après refus
  Après un clic sur « Refuser tout », lecture des états de consentement dans
  le dataLayer. Vérification que analytics_storage et ad_storage sont bien
  en « denied » lorsque l’utilisateur a refusé.

---

7. SCRIPTS ET CONTENUS TIERS AVANT CONSENTEMENT

• Scripts de tracking chargés avant le choix de l’utilisateur
  Inventaire des scripts tiers (Google Analytics, GTM, Facebook Pixel, Hotjar,
  LinkedIn, TikTok, Matomo, etc.) chargés sur la page. Une attention
  particulière est portée aux scripts insérés dans le , susceptibles
  de s’exécuter avant toute interaction avec la bannière.
• Iframes de services tiers
  Détection des iframes de services tiers (YouTube, Vimeo, Google Maps,
  widgets sociaux, etc.) chargés dès l’affichage de la page, sans
  consentement préalable.

---

8. PERSISTANCE DU CHOIX DE L’UTILISATEUR

• Enregistrement du refus dans un cookie
  Après un clic sur « Refuser tout », vérification qu’au moins un cookie
  (ou une clé de stockage) lié au consentement est créé ou mis à jour,
  afin que le choix soit pris en compte lors des visites suivantes.
• Indicateur explicite de refus
  Analyse de la valeur des cookies de consentement pour détecter la présence
  d’un indicateur clair de refus (rejected, denied, false, etc.), afin
  d’assurer la traçabilité du choix.

---

9. IDENTIFICATION DES SERVICES DE SUIVIS

• Classification des services par leurs cookies
  À partir des noms de cookies, identification des services (Google Analytics,
  Facebook Pixel, Hotjar, LinkedIn, Matomo, OneTrust, Complianz, etc.) et
  rattachement à une catégorie : analytics, publicité, gestion du
  consentement, marketing automation ou infrastructure. Ce travail permet
  de présenter des résultats plus clair (« Google Analytics détecté » plutôt
  que des identifiants techniques).

---

10. COOKIES TIERS ET COOKIES « ZOMBIES »

• Comptage des cookies tiers
  Pour chaque cookie, comparaison du domaine du cookie avec le domaine du site
  (eTLD+1). Les cookies dont le domaine ne correspond pas au site sont
  comptabilisés comme cookies tiers.
• Détection des cookies zombies
  Après suppression de tous les cookies et rechargement de la page, vérification
  qu’aucun cookie ne réapparaît sans nouvelle action de l’utilisateur. La
  réapparition de cookies après purge signale des techniques de type
  « evercookie » ou similaires, incompatibles avec le droit à l’effacement.

---

11. CONTEXTES ADDITIONNELS

• Test de navigation interne
  Visite de plusieurs pages internes du site (liens trouvés sur la page
  d’accueil) et comparaison des cookies avant/après navigation, pour
  détecter des dépôts de cookies déclenchés au fil de la navigation.
• Détection de CAPTCHA ou WAF
  Repérage de signaux indiquant une page de défi (CAPTCHA, WAF, Cloudflare,
  etc.), pouvant limiter la portée de l’analyse et mentionnés dans les
  limitations du rapport.
• Gestion des blocages d’accès
  En cas d’échec du chargement (par exemple 403), plusieurs stratégies de
  requête sont essayées (User-Agent, paramètres navigateur) pour tenter
  d’obtenir un résultat exploitable.

Dans le contexte de la Loi 25 sur la protection des renseignements personnels au Québec, la sécurité des communications entre un site web et ses visiteurs constitue une mesure de protection de base.

Lorsqu’une organisation collecte ou transmet des renseignements personnels par l’entremise de son site web, elle doit s’assurer que ces échanges sont protégés contre l’interception ou l’altération.

Loi25.certi360.com fait donc une série de tests techniques pour vérifier si les communications web sont chiffrées de manière raisonnable.

Ces tests n’ont pas pour objectif de déterminer la conformité légale à la Loi 25, ni d’évaluer la sécurité globale d’une infrastructure.  Ils servent plutôt à sensibiliser les organisations, en particulier les PME, aux bases essentielles de la protection des données en transit.

Pourquoi tester le chiffrement TLS/SSL

La Loi 25 n’impose pas une technologie précise ni un niveau de chiffrement spécifique. Elle exige toutefois que les renseignements personnels soient protégés par des mesures de sécurité raisonnables, notamment lors de leur transmission sur Internet.

Le chiffrement TLS (Transport Layer Security), souvent appelé SSL par abus de langage, est le mécanisme standard utilisé par les navigateurs pour sécuriser les échanges HTTP. Lorsqu’il est correctement configuré, il empêche qu’un tiers puisse lire ou modifier les données échangées entre le site web et l’utilisateur.

Un chiffrement absent, invalide ou faible constitue un signal de risque clair du manque de mesure de base. 

Les tests effectués par Loi25.certi360.com

1. Vérification HTTPS seulement

Objectif du test

Ce test vérifie si le site web est accessible uniquement via HTTPS et si toute tentative d’accès en HTTP est automatiquement redirigée vers HTTPS.

Comment le test est réalisé

L’outil tente d’accéder au site en HTTP (port 80) et observe la réponse du serveur. Une redirection permanente (301) ou temporaire (302) vers une URL HTTPS est considérée comme une configuration sécurisée.

Comment interpréter le résultat

Un résultat positif indique que les visiteurs sont automatiquement protégés, même s’ils saisissent une adresse non sécurisée. Un échec signifie que des données pourraient transiter en clair, ce qui représente une mauvaise pratique dans le contexte de la Loi 25.

2. Validité du certificat TLS

Objectif du test

Ce test vérifie que le certificat utilisé par le site web est valide, reconnu et non expiré.

Comment le test est réalisé

L’outil établit une connexion TLS avec le site et valide la chaîne de certification à l’aide de règles équivalentes à celles d’un navigateur moderne. Il vérifie notamment la date d’expiration et l’autorité de certification.

Comment interpréter le résultat** pour une PME**

Un certificat valide signifie que les navigateurs peuvent établir une connexion sécurisée sans alerte. Un certificat expiré ou non reconnu entraînera des messages de sécurité bloquants pour les utilisateurs, ce qui est incompatible avec une protection raisonnable des renseignements personnels.

3. Correspondance entre le nom de domaine et le certificat

Objectif du test

Ce test s’assure que le certificat TLS est bien émis pour le nom de domaine du site analysé.

Comment le test est réalisé

L’outil compare le nom de domaine du site avec les champs de validation du certificat (CN et SAN). Toute incohérence entraîne l’échec du test.

Comment interpréter le résultat

Un certificat qui ne correspond pas au domaine est perçu comme non fiable par les navigateurs. Même si le chiffrement est techniquement présent, la connexion sera bloquée ou signalée comme dangereuse.

4. Protocoles TLS utilisés

Objectif du test

Ce test vérifie que le serveur utilise des versions de TLS encore considérées comme sécurisées par les navigateurs modernes.

Comment le test est réalisé

L’outil tente de négocier une connexion TLS et identifie les protocoles supportés par le serveur. Les versions TLS 1.2 et TLS 1.3 sont actuellement considérées comme sécurisées.

Comment interpréter le résultat

Un serveur qui supporte uniquement des protocoles obsolètes expose les communications à des risques connus. La présence de TLS 1.2 ou 1.3 indique une configuration alignée avec les pratiques actuelles.

5. Absence d’erreurs bloquantes côté navigateur

Objectif du test

Ce test vise à confirmer qu’un navigateur moderne peut accéder au site sans afficher d’alerte de sécurité bloquante.

Comment le test est réalisé

L’outil simule une connexion TLS stricte, équivalente à celle d’un navigateur récent, et vérifie qu’aucune erreur critique n’est détectée lors de l’établissement de la connexion.

Comment interpréter le résultat

L’absence d’erreurs bloquantes signifie que les utilisateurs peuvent naviguer sur le site sans avertissement de sécurité. La présence d’une alerte critique indique un problème sérieux qui nuit à la confiance et à la protection des données.

Ce que ces tests signifient

Les tests TLS/SSL de Loi25.certi360.com permettent d’observer si les communications web sont chiffrées de manière raisonnable et acceptée par les navigateurs modernes.

Attention: Ils ne constituent pas une preuve de conformité à la Loi 25 et ne remplacent ni une analyse juridique ni un audit de sécurité.

---

Après mes derniers audits ISO 27001, je vois la même erreur.

Des entreprise qui déclarent applicables des contrôles qui n’ont aucun rapport avec leur réalité. Ils se compliquent la vie, perdent du temps, et dépensent de l’argent inutilement.

Le pire cas, une firme de services financiers avec aucun développeur et aucune ligne de code qui s’est imposé tous les contrôles de la norme. Leur consultant les avait convaincus que “c’était plus sûr comme ça”.

Si votre entreprise ne développe pas de logiciels, certains contrôles de l’ISO 27001:2022 ne s’appliquent pas à vous.

Dans mes audits, je constate que 70% des entreprises sans développement déclarent quand même applicables des contrôles qu’elles n’ont pas d’affaire à implémenter. Pour trois raisons:

Première raison : Leur consultant a peur. Il préfère dire “applicable” que de justifier pourquoi ce ne l’est pas. Plus facile de facturer des heures supplémentaires que d’expliquer la logique derrière une déclaration de non-applicabilité.

Deuxième raison : La direction pense qu’être “plus strict” c’est mieux. Non. C’est juste plus cher et plus compliqué pour rien.

Troisième raison : Personne n’a pris le temps de bien comprendre ce que fait réellement l’entreprise. On applique un “template” générique au lieu d’analyser le contexte spécifique.

---

Voici les contrôles non applicables

Quand votre entreprise ne fait aucun développement logiciel, ces cinq contrôles ne s’appliquent pas :

A8.4 — Accès au code source, clairement si nous n’avons pas de développement, il n’y a pas de code source à gérer!

A.8.25 — Cycle de vie de développement sécurisé Si vous n’avez pas d’équipe de développement, vous n’avez pas de cycle de développement.

A.8.26 — Exigences de sécurité applicatives Ce contrôle concerne les spécifications de sécurité pour vos propres applications. Pas celles que vous achetez ou louez. Si vous ne développez rien, ce contrôle ne vous concerne pas.

A.8.27 — Architecture sécurisée et principes d’ingénierie Porte sur la conception sécurisée des systèmes que vous développez. Encore une fois, sans développement, pas d’architecture à concevoir.

A.8.28 — Codage sécurisé Le plus évident. Pas de code, pas de codage sécurisé. Certaines entreprises pensent que configurer un logiciel c’est du “codage”. Non, c’est de la configuration.

A.8.29 — Tests de sécurité dans le développement Tests de sécurité sur le code en développement. Sans développement, ce contrôle tombe à l’eau.

Les zones grises qui créent la confusion

Trois contrôles créent souvent de la confusion :

A.8.30 — Développement externalisé Celui-là, c’est plus subtil. Si vous engagez des programmeurs externes pour développer quelque chose spécifiquement pour vous, ce contrôle s’applique. Mais si vous achetez un logiciel sur une étagère, même personnalisé, ça ne compte pas comme du développement externalisé.

A.8.31 — Séparation des environnements Pas besoin d’environnement de développement si vous ne développez pas. Par contre, si vous avez un environnement de test pour vos logiciels achetés, ce contrôle pourrait s’appliquer partiellement.

A.8.33 — Informations de test Si vous ne testez jamais rien, ce contrôle ne s’applique pas. Mais attention : la plupart des entreprises font au moins des tests d’acceptation sur leurs nouveaux logiciels.

Ce qui reste applicable

Le contrôle 8.32 — Gestion des changements reste presque toujours applicable, même sans développement. Parce que vous changez des configurations, mettez à jour des logiciels, modifiez des paramètres. Ça, c’est de la gestion des changements.

Pour les autres contrôles, tel que sécurité réseau, de gestion des accès, de sauvegarde, de formation ? Ils restent applicables puisqu’avec ou sans développement, ces mesures protègent votre environnement informatique, peu importe d’où viennent vos logiciels.

Comment bien évaluer l’applicabilité

Posez-vous ces questions simples :

• Est-ce que quelqu’un dans mon entreprise écrit du code ?
• Est-ce que nous avons des programmeurs à l’interne ?
• Est-ce que nous engageons des firmes pour développer des applications spécifiquement pour nous ?
• Est-ce que nous modifions le code source de nos logiciels ?

Si toutes les réponses sont “non”, alors les contrôles A8.4, 8.25 à 8.29 ne s’appliquent pas à vous.

La justification, c’est obligatoire

Quand vous déclarez un contrôle non applicable, vous devez le justifier par écrit dans votre Déclaration d’Applicabilité. Ce n’est pas optionnel, c’est une exigence de la norme.

Une bonne justification ressemble à ça :

“L’entreprise ne développe aucun logiciel à l’interne et ne fait appel à aucun fournisseur qui fait du développement. Tous les logiciels utilisés sont des solutions commerciales acquises sur le marché.”

Attention aux changements

Votre déclaration d’applicabilité n’est pas gravée dans le béton. Si votre entreprise évolue et commence à faire du développement, vous devrez réviser cette déclaration.

J’ai vu des entreprises qui ont commencé par acheter des logiciels, puis qui ont engagé des programmeurs pour les personnaliser. Du jour au lendemain, certains contrôles sont redevenus applicables.

---

Je vous invite à cliquer sur “Follow” pour continuer d’en apprendre plus sur les sujets liés à la sécurité de l’information et à la vie privée.

---

En premier, il faut savoir que Le Top 10 est un document de sensibilisation qui explique les principaux risques applicatifs, c’est parfait pour l’éducation, l’auto-évaluation rapide et les « quick wins ».

De l’autre côté, L’ASVS est un cadre de travail exhaustif d’exigences , pour bâtir, tester et valider des applications de façon systématique.

---

Ce qu’est le OWASP Top 10

Le OWASP Top 10 est une liste des dix vulnérabilités de sécurité web les plus courantes, destiné à sensibiliser les développeurs et les organisations aux risques les plus prioritaires à corriger ou surveiller.

Voici les 10 plus grands risques associés à une application web pour la version 2021. (une nouvelle version devrait être publiée en 2025.)

• A01 — Contrôles d’accès défaillants
• A02 — Cryptographie et protection des données inadéquates
• A03 — Injection
• A04 — Conception non sécurisée
• A05 — Vulnérabilités de sécurité liées aux composants
• A06 — Mauvaises configurations de sécurité
• A07 — Identification et authentification faibles
• A08 — Gestion des erreurs et journalisations insuffisantes
• A09 — Contrôle d’intégrité des données
• A10 — Sécurité côté client

Son but est sensibilisé et aider la formation des gens sur les risques des applications Web.

---

Ce qu’est l’OWASP ASVS

L’Application Security Verification Standard (ASVS) fournit une liste détaillée d’exigences techniques pour concevoir, développer et vérifier la sécurité des applications et services web.

Vous pouvez libre mon billet d’introduction ici: https://medium.com/@btk667/owasp-asvs-cest-quoi-9ffd3cb06ad9

C’est un cadre structuré, pensé pour des tests et une intégration dans le SDLC. La version stable actuelle est ASVS 5.0.0.

Chaque exigence est identifiable et formulée de façon vérifiable — pratique pour l’acceptation lors des revues de code, les tests ou un audit externe.

ASVS est organisé par chapitres couvrant tous les aspects de développement web. Autant l’architecture, la conception, authentification et gestion des identifiants, sessions, contrôle d’accès, validation/encodage, cryptographie, journalisation et gestion des erreurs, protection des données, communications, intégrité du code, logique d’affaires, fichiers/ressources, API et configuration.

L’organisation OWASP offre même des Cheat Sheet pour mieux comprendre et gérer les contrôles dans les opérations courantes.

Cheat Sheet OWASP

---

Quand utiliser l’un ou l’autre

Le Top 10 c’est pour démarrer ou débuter dans la construction d’une culture sécurité en formant les équipes de développeurs, créer des listes de vérification et obtenir des victoires rapides à court terme.

Mais si on veut construire plus sérieusement et surtout valider notre travail de manière méthodique, il faut intégrer l’ASVS au SDLC, on commence par le premier niveau, puis on progresse à mesure que notre maturité augmente. Notre maturité augmente en même temps que la qualité de nos outils, de nos procédures et que ceux-ci sont répétable rapidement.

---

Effort et coûts

Top 10
Faible coût pour formation, liste, corrections ciblées.

Impact rapide sur l’hygiène de base, mais attention : couverture partielle des risques et peu de traçabilité fine.

ASVS
Investissement plus important avec des sélection d’exigences, adaptation au SDLC, ajout de tests (automatisés et manuels), collecte de preuves.

Impact réduction du risque résiduel et meilleure démonstration de conformité pour vos clients et fournisseurs.

---

Je vous invite à cliquer sur “Follow” pour continuer d’en apprendre plus sur les sujets liés à la sécurité de l’information et à la vie privée.