Sujet demandé par Eric les 28-29 juin. Angle validé par Eric : au-delà d'un outil précis, tout ce qui génère du Shadow IT quand le pare-feu n'est pas paramétré. Cible : dirigeants qui croient être protégés parce qu'ils « ont un pare-feu ». Levier : un boîtier laissé sur ses réglages d'usine donne une fausse sécurité.
« Un collaborateur installe un petit logiciel bien pratique · en trois minutes, il a ouvert une porte que votre pare-feu ne voit même pas. » Scène concrète, sans malveillance, à laquelle tout dirigeant peut associer un visage dans son équipe.
On nomme le Shadow IT (outils installés hors du contrôle informatique), puis la bascule : un pare-feu laissé sur ses réglages d'usine ne protège pas. Cinq gestes concrets de paramétrage (filtrer le sortant, bloquer les tunnels/VPN, contrôler les installations, segmenter, surveiller). Angle élargi comme Eric l'a demandé : pas un seul outil visé, mais tout ce qui génère du Shadow IT.
Question binaire, sans jargon, qui remet en cause la fausse sécurité. La punchline « nous créerions nous-mêmes la faille » (formule d'Eric) ancre l'exigence et la crédibilité de prestataire. Le 1er commentaire ouvre une revue courte signée Eric.
Demande d'Eric : partir d'un cas concret (outil de tunnel installé par un collaborateur) puis, sur sa précision du 29/06, « le prendre sous l'angle de tout ce qui peut générer du Shadow IT si le pare-feu n'est pas configuré ». Le post ne nomme aucun produit précis - il parle de « tunnels et VPN grand public » en général.
Rien d'inventé : pas de chiffre, pas de nom de marque, pas de cas client identifiable. Uniquement des principes de configuration standards (filtrage sortant, blocage des catégories de tunnel, contrôle des installations, segmentation, supervision).
Publication : après la fin de la série « Anatomie d'une cyberattaque » (10/10). À valider par Eric.