Discipline : Cybersécurité et résilience numérique

Protection des systèmes contre menaces IA (deepfakes, phishing) et garantie de continuité via sécurité post-quantique, chiffrement et sauvegardes locales.
Résilience numérique, sécurité post-quantique, deepfake, vieillissement caché, borg, rsync, souveraineté des identités

  • Dataset FAIR

    Données conçues pour être trouvées, comprises et réutilisées par des humains et des machines sans dépendre d’un intermédiaire centralisé.

    Un dataset FAIR n’est pas une théorie abstraite : c’est une manière pratique de préparer, documenter et partager des données pour qu’elles soient immédiatement utiles à vous, à vos collègues, à une API, ou à un futur projet.

    Le jeu de données est conçu selon les principes FAIR Findable (trouvable), Accessible (accessible), Interoperable (interopérable), Reusable (réutilisable) afin de maximiser sa découvrabilité, sa réutilisation éthique et sa persistance, sans dépendre des plateformes propriétaires.

    Les 4 piliers :

    • Findable : doté d’un identifiant persistant (ex. : DOI, handle, CID IPFS) et de métadonnées riches (ex. : JSON-LD, Schema.org).
    • Accessible : téléchargeable via un protocole ouvert (HTTP, IPFS), même si l’accès est restreint (ex. : authentification, licence).
    • Interoperable : utilise des formats ouverts (CSV, JSON, RDF) et des vocabulaires partagés (ex. : Wikidata, ISO 639-3 pour les langues).
    • Reusable : accompagné d’une licence claire (ex. : CC-BY-SA, ODC-BY) et de contexte (auteurs, langue, usage visé).

    Pourquoi c’est important ?

    Parce que dans la vraie vie, les chercheurs, les journalistes, les professeurs ou les citoyens ont besoin de données fiables et partageables pour :

    • Comprendre le climat,
    • Sauver des vies avec la médecine,
    • Protéger les langues rares,
    • Ou créer des outils utiles pour tout le monde.

    Mais si les données sont cachées, mal rangées, sans explication ou verrouillées, elles deviennent inutiles.

    Exemple concret

    Vous exportez la liste des utilisateurs inscrits à une formation en ligne (anonymisés) :

    • Non FAIR : liste_participants.xlsx envoyé par email.
    • FAIR :
      • Fichier participants.csv + metadata.json (avec Schema.org),
      • Hébergé sur GitHub avec DOI via Zenodo,
      • Licence : CC BY 4.0,
      • Champs : user_id (UUID), signup_date (ISO 8601), country (code ISO 3166),
      • README expliquant la méthodologie et la politique d’anonymisation.

    Un chercheur en éducation peut intégrer vos données dans une méta-analyse mondiale… sans vous relancer.

    Pourquoi c’est utile ?

    • Automatisation : vos propres outils peuvent consommer ces données plus tard.
    • Crédit : chaque réutilisation cite votre travail.
    • Conformité : exigence croissante des financeurs publics (ANR, UE, etc.).
    • Impact : vos données deviennent une ressource du commun numérique, pas un fichier mort.

    FAIR, c’est transformer un simple export de base de données en une brique réutilisable de l’infrastructure numérique publique.

  • Honeypot

    Champ de formulaire caché, invisible aux humains mais visible aux robots, utilisé pour détecter et bloquer les soumissions automatisées.

    Un honeypot (littéralement « pot à miel ») est une technique de sécurité passive consistant à ajouter un ou plusieurs champs de formulaire dissimulés (via CSS ou HTML sémantique) dans un formulaire web.

    Ces champs sont intentionnellement laissés vides par les utilisateurs humains, car non visibles ni accessibles via la navigation clavier ou les lecteurs d’écran (grâce à un balisage approprié : aria-hidden="true", display: none ou positionnement hors écran avec respect des critères RGAA).

    En revanche, les robots de spam, qui remplissent systématiquement tous les champs d’un formulaire, y insèrent souvent une valeur. Si ce champ « piège » est rempli lors de la soumission, le serveur rejette la requête comme suspecte, sans perturber l’expérience utilisateur légitime.

    Caractéristiques clés :

    • 100 % invisible et sans friction pour l’utilisateur humain
    • Aucune dépendance à JavaScript (peut fonctionner en HTML pur)
    • Entièrement compatible avec l’accessibilité si correctement implémenté
    • Très efficace contre le spam basique (scrapers, bots simples)

    Bonnes pratiques d’implémentation :

    • Utiliser un nom de champ trompeur (ex. phone, website, company) pour leurrer les bots
    • Cacher le champ sans le supprimer du DOM (sinon les bots ne le voient pas)
    • S’assurer qu’il est inaccessible au clavier et invisible aux technologies d’assistance
    • Ne pas en abuser : un seul honeypot suffit par formulaire

    Limites :

    • Moins efficace contre les bots avancés qui ignorent les champs cachés
    • Nécessite une validation côté serveur (jamais côté client seul)

    Usage éthique : technique sobre, auto-hébergeable, sans tiers ni traceur idéale pour les sites sensibles à la vie privée, à l’accessibilité et à la performance.

    Le honeypot est une technique de sécurité passive au niveau applicatif ou infrastructurel. Il s’agit d’un mécanisme de défense contre les abus, proche de la sécurité applicative ou de la protection des services.

    • Continuité de service : car le honeypot contribue à maintenir la disponibilité des formulaires en bloquant le spam
    • Infrastructure numérique : car il s’agit d’un composant de la chaîne de sécurité d’un service web

  • Consultant cybersécurité

    Gardien de la souveraineté numérique, pas technicien de l’urgence.

    Idées reçues fréquentes

    Il protège les systèmes en installant des antivirus, en bloquant des attaques en temps réel ou en « piratant pour le bien ».

    Cette vision réductrice confond réaction immédiate et résilience structurelle. Elle oublie que la vraie sécurité ne se mesure pas en attaques repoussées, mais en capacités préservées, en libertés maintenues, et en infrastructure maîtrisée.

    Ses missions

    Le Consultant cybersécurité accompagne les organisations dans la conception et la mise en œuvre d’une posture de sécurité alignée sur leurs valeurs, leurs risques réels et leur capacité de maintien en conditions dégradées.

    Il évalue les vulnérabilités techniques, humaines et organisationnelles, propose des mesures proportionnées (chiffrement, sauvegardes, gestion des accès, auto-hébergement), et forme les équipes à une culture de la vigilance sobre, pas de la paranoïa.

    Il privilégie les solutions open source, auditables, auto-hébergées (ex. : NAS chiffré, rsync + Borg, DDEV en local) et refuse les promesses de sécurité « clé en main » qui créent de la dépendance.

    Le sens du métier

    Protéger non pas les données comme des actifs à sécuriser, mais les personnes comme des sujets à émanciper en leur rendant le contrôle sur leurs outils, leurs communications et leurs archives.

    Champ d’action

    • Cartographier les actifs critiques (documents, contacts, bases de données)
    • Évaluer les menaces réalistes (pas les scénarios hollywoodiens)
    • Concevoir des stratégies de sauvegarde, de restauration et de continuité (ex. : 3-2-1 avec chiffrement)
    • Auditer les outils et services : stockage cloud, messagerie, CMS, hébergement
    • Recommender des alternatives souveraines et résilientes (Proton Mail, Tails, NAS, Raspberry Pi)
    • Former aux bonnes pratiques : mots de passe, double authentification, gestion des permissions
    • Documenter les procédures de réponse aux incidents (sans dramatisation)

    Outils et terrains

    GPG, VeraCrypt, BorgBackup, rsync, rclone, KeePassXC, Tails, Fail2Ban, OpenSSH, outils d’audit réseau (Nmap, Lynis), frameworks comme ISO 27001 ou ANSSI (avec adaptation pragmatique)
    (Préférence marquée pour les outils libres, scriptables, offline-first, sans compte ni cloud centralisé)

    Confusions fréquentes

    Pas un pentester spectacle : il ne cherche pas à « casser » pour impressionner, mais à renforcer discrètement.

    Pas un vendeur de solutions : il ne propose pas de « suite sécurité », mais des gestes reproductibles et transmissibles.

    Pas un informaticien système : il ne gère pas l’infrastructure au quotidien, mais en garantit la résilience éthique.

    Rémunération indicative (France, brut annuel)

    – Junior (0–3 ans) : 40 000 € – 50 000 €
    – Confirmé·e (3–6 ans) : 50 000 € – 70 000 €
    – Senior / Lead (6+ ans, avec expertise en souveraineté ou sécurité éthique) : 70 000 € – 95 000 €+
    (Les consultants indépendants spécialisés en sécurité pour acteurs culturels, associatifs ou éducatifs peuvent facturer moins, mais avec un impact plus aligné sur leurs valeurs.)

    Où le rencontrer ?

    Collectifs de défense des droits numériques, associations, médiathèques, éditeurs indépendants, écoles alternatives, structures de l’ESS, cabinets de conseil éthiques, hackerspaces engagés — et de plus en plus, dans des environnements auto-hébergés avec un NAS, une clé USB live et un Raspberry Pi en projet.

    Autres appellations

    Conseiller en sécurité numérique, Consultant en souveraineté technologique, Spécialiste en résilience numérique, Ingénieur·e sécurité éthique

  • Rate limiting

    Mécanisme de sécurité qui limite le nombre de requêtes qu’un utilisateur (ou une IP) peut effectuer sur une ressource donnée dans un laps de temps défini, afin de prévenir les abus automatisés.

    Le rate limiting (ou limitation de débit) consiste à restreindre la fréquence des actions (ex. envois de formulaires, tentatives de connexion, requêtes API) provenant d’une même source (IP, session, compte utilisateur) sur une période donnée (ex. 5 requêtes par minute).

    Cette mesure vise à détecter et bloquer les comportements anormaux typiques des bots (soumissions massives, attaques par force brute, scraping intensif), tout en préservant une expérience fluide pour les humains, dont le rythme d’interaction reste naturellement limité.

    Caractéristiques clés :

    • Transparent pour l’utilisateur légitime
    • Effet dissuasif contre les attaques automatisées
    • Implémentable côté serveur, proxy (ex. Nginx), ou middleware
    • Aucun impact sur l’accessibilité (pas de défi perceptif ou moteur)

    Exemples de seuils courants :

    • 3 tentatives de connexion échouées → blocage temporaire
    • 10 soumissions de formulaire par heure par IP
    • 100 requêtes API par minute par token d’authentification

    Bonnes pratiques :

    • Fournir un message clair en cas de dépassement (ex. « Trop de tentatives. Réessayez dans 5 minutes. »)
    • Prévoir des exceptions pour les réseaux partagés (écoles, entreprises, bibliothèques) via des listes blanches ou l’identification par compte
    • Coupler avec d’autres mesures (honeypot, vérification temporelle) pour éviter les faux positifs

    Limites :

    • Peut affecter les utilisateurs derrière une même IP (NAT, proxies publics)
    • Moins efficace contre les attaques distribuées (DDoS, botnets à IP multiples)

    Usage éthique : technique sobre, décentralisable, sans recours à des services externes — s’intègre parfaitement dans une infrastructure auto-hébergée (ex. via Nginx, Apache mod_evasive, ou règles DDEV/OmniTools).

  • CAPTCHA accessible ou passif

    Un captcha passif est un mécanisme anti-robots qui protège les formulaires ou interactions numériques sans imposer de test perceptif (visuel, auditif) ou moteur à l’utilisateur, tout en restant utilisable par les personnes en situation de handicap, notamment celles utilisant des technologies d’assistance.

    Cette méthode vérifie que l’utilisateur est un humain en évitant toute exclusion fondée sur l’aptitude sensorielle, motrice ou cognitive.

    Contrairement aux CAPTCHA traditionnels (reconnaissance d’images, transcription de sons, puzzles interactifs), il repose sur des signaux contextuels, comportementaux ou logiques, tels que le temps de remplissage d’un formulaire, la navigation au clavier, la cohérence des actions, ou l’analyse invisible du trafic.

    Ces systèmes peuvent être entièrement invisibles (ex. Cloudflare Turnstile), adaptatifs (déclenchement conditionnel selon un score de risque), ou textuels simples (questions claires, balisées ARIA, compatibles avec les lecteurs d’écran).

    Ils respectent les principes Percevable, Operable, Understandable des WCAG et les exigences du RGAA (Référentiel général d’amélioration de l’accessibilité) en matière d’équité d’usage.

    Exemples de techniques incluses :

    • Analyse comportementale en arrière-plan (Turnstile, reCAPTCHA Enterprise invisble)
    • Défis textuels simples, correctement balisés
    • Honeypots + limitation de débit + vérification temporelle
    • Attribution d’un score de risque sans intervention utilisateur

    Critères d’accessibilité respectés :

    • Pas d’obligation de vision, d’audition ou de précision gestuelle
    • Compatibilité avec les lecteurs d’écran et la navigation clavier
    • Absence de discrimination cognitive ou linguistique
    • Transparence partielle ou totale de l’expérience utilisateur

    Les CAPTCHA passifs représentent aujourd’hui la solution la plus inclusive et efficace contre les bots modernes. Leur adoption répond à la fois à des impératifs d’accessibilité légale (RGAA, EN 301 549) et à une exigence d’expérience utilisateur fluide.

  • Cyberrésilience

    La cyberrésilience, c’est la capacité d’une entreprise à « rebondir » après un problème numérique grave , comme une cyberattaque, une panne informatique ou une faille de sécurité.

    C’est comme l’immunité numérique d’une organisation : elle ne cherche pas seulement à éviter les coups, mais aussi à les encaisser, y faire face et s’en remettre rapidement, sans que cela ne bloque son activité.

    Son but est de maintenir la continuité des activités même en situation de crise.

    • Elle inclut la gestion de crise
    • Elle prend en compte la continuité métier
    • Elle implique tous les niveaux de l’entreprise (technique, juridique, communication…)
    • Le préfixe « cyber- » est soudé au mot qu’il précède lorsqu’il forme un composé lexical stable.
    • Exemples analogues : cybersécurité, cyberharcèlement, cyberattaque, cyberespace.
    • La forme « cyber résilience » (en deux mots) est parfois utilisée à l’oral ou dans des textes non normalisés, mais elle n’est pas conforme à la norme linguistique en usage dans les documents techniques, administratifs ou académiques francophones.

  • VulDB

    VulDB est une base de données centralisée qui recense, analyse et documente les failles de sécurité informatique détectées dans divers systèmes, logiciels et infrastructures.

    Principales caractéristiques

    • Référencement des vulnérabilités : chaque faille est identifiée par un identifiant unique, facilitant ainsi le suivi et la gestion des vulnérabilités.
    • Mises à jour en temps réel : les informations sur les menaces connues sont régulièrement mises à jour pour refléter l’évolution des risques.
    • Informations détaillées : VulDB fournit des données précises, notamment le score de criticité CVSS, l’impact potentiel et l’exploitabilité des vulnérabilités.
    • Sources multiples : les données proviennent de contributions communautaires, de rapports de chercheurs en cybersécurité et d’alertes des éditeurs de logiciels.
    • Outils de veille et d’analyse : VulDB offre des outils pour anticiper les risques et protéger les systèmes contre les attaques potentielles.
    • Utilisation professionnelle : VulDB est principalement utilisé par les professionnels de la cybersécurité, les équipes SOC et les analystes en gestion des risques pour suivre et atténuer les menaces de sécurité avant qu’elles ne soient exploitées.

    Synonyme : Vulnerability Database

    Vuldb.com

  • WAF IA

    Les pare-feux d’application Web basés sur l’IA utilisent l’intelligence artificielle pour analyser le trafic web en temps réel et détecter les menaces.

    Ils sont particulièrement efficaces contre les attaques zero-day, exploitant des failles encore inconnues.

    Plugins WAF recommandés pour WordPress :

    • Sucuri
    • Wordfence
    • Shield Security

    Synonyme :  WAF basé sur l’IA

  • CID

    Le CID, c’est s’assurer que les bonnes personnes voient les bonnes données, que ces données ne sont pas altérées, et que tout reste accessible au bon moment.

    LettreMotCe que ça veut dire
    CConfidentialitéSeuls les bons yeux voient les bonnes infos.
    IIntégritéLes données ne changent pas toutes seules.
    DDisponibilitéLe service marche quand on en a besoin.
    PilierQuestion cléBonne pratique associée
    ConfidentialitéQui peut voir ça ?Authentification forte, gestion des rôles, chiffrement
    IntégritéEst-ce bien l’original ?Hachage (SHA-256), contrôle de version, WAF
    DisponibilitéEst-ce accessible maintenant ?Sauvegardes, redondance, monitoring, pare-feu

    Exemple du quotidien :

    Imaginez une boîte aux lettres numérique :

    • Confidentialité → Seul le destinataire peut ouvrir sa boîte.
    • Intégrité → Le message à l’intérieur n’a pas été modifié en route.
    • Disponibilité → La boîte est ouvrable à tout moment, sans erreur.

    Ce modèle est utilisé partout : dans les écoles, les hôpitaux, les sites web, les banques…
    C’est la base de toute sécurité numérique sérieuse.

  • Logic bomb

    Une logic bomb (ou bombe logique) est un morceau de code malveillant inséré délibérément dans un système informatique, qui s’exécute lorsqu’une condition prédéfinie est remplie (date, événement, action utilisateur, etc.), provoquant un dommage ciblé : suppression de données, arrêt de service, fuite d’informations, etc.

    Contrairement à un virus ou un ransomware, elle n’est pas auto-réplicante : elle attend passivement son déclencheur.

    Caractéristiques clés

    AspectDétail
    NatureCode malveillant dormant (« sleeper code »)
    DéclencheurCondition logique :<br>– Date/heure précise (« le 1er janvier 2027 »)<br>– Événement système (« si l’utilisateur X est supprimé »)<br>– Action (« après 100 connexions échouées »)
    ObjectifSabotage, vengeance, espionnage, destruction
    Cible typiqueEntreprises, institutions critiques, anciens employés malveillants

    Exemple concret

    Un développeur licencié insère, avant son départ, une ligne de code dans le logiciel de paie de son entreprise :

    Code en Python

    if current_date == "2026-12-31":
    delete_all_payroll_records()

    → Le 31 décembre 2026, au moment de la clôture annuelle, toutes les données de paie sont effacées.
    → Le code était inoffensif pendant un an → difficile à détecter.

    Différence avec d’autres menaces

    MenaceAuto-réplication ?DéclenchementExemple
    Logic bombNonCondition logiqueCode dormant activé le jour J
    VirusOuiÀ l’exécution d’un fichierInfecte d’autres programmes
    RansomwareOuiImmédiat ou différéChiffre les fichiers dès l’entrée
    BackdoorNonÀ la demande du pirateAccès caché permanent

    Contextes à risque

    • Départs conflictuels d’employés avec accès privilégié (développeurs, admins système)
    • Logiciels propriétaires non audités (code opaque)
    • Systèmes critiques (industrie, santé, finance) où un arrêt coûte cher
    • Supply chain attacks : une mise à jour légitime contient une logic bomb

    Mesures de protection (pour un RSSI)

    1. Audit de code (revue par pairs, outils SAST/SCA)
    2. Principe du moindre privilège : limiter les accès au code source et aux systèmes critiques
    3. Gestion des départs : révoquer immédiatement les accès, scanner les dépôts
    4. Surveillance des logs : détecter les modifications suspectes (ex. : code ajouté sans revue)
    5. Backups hors ligne et testés : pour restaurer après une destruction

    Aspect juridique (France / UE)

    Insérer une logic bomb est un délit pénal :

    • Article 323-3 du Code pénal (France) : « Entrave au fonctionnement d’un système de traitement automatisé de données » → jusqu’à 5 ans de prison et 150 000 € d’amende.
    • Si données personnelles concernées → RGPD (sanctions jusqu’à 4 % du CA mondial).

    Une logic bomb est une arme logicielle à retardement, conçue pour frapper quand on s’y attend le moins. Elle exploite non pas une faille technique, mais une faille humaine ou organisationnelle.