7ASecurity audited zlib with OSTIF and the Sovereign Tech Fund: 10 security findings (1 high), all fixed and verified, plus guidance.
Je suis impressionné par la qualité du rapport (https://7asecurity.com/reports/pentest-report-zlib-RC1.1.pdf) et l'efficacité de Mark Adler (le créateur).
Selon le dernier baromètre publié par le CESIN, 81 % des entreprises interrogées estiment disposer d’une vision complète de leurs actifs, tandis que 92 % ont identifié ou sont en cours d’identification de leurs actifs critiques. Si la maturité cyber progresse au sein des entreprises françaises, la complexité des infrastructures hybrides continue toutefois d’ouvrir des […]
The post Cyberdéfense : la visibilité réseau, le chaînon manquant de la résilience des entreprises first appeared on UnderNews.
Vous avez déjà remarqué comment le volume varie d'une vidéo à l'autre sur YouTube, ou pire, comment certaines pubs sont 10 fois plus fortes que le contenu ? Bah c'est parce que tout le monde n'utilise pas la même norme de volume. Et si vous produisez du contenu audio/vidéo, c'est le genre de détail qui fait la différence entre un truc amateur et un rendu pro.
La bonne nouvelle, c'est que FFmpeg intègre déjà un filtre qui s'appelle loudnorm et qui gère tout ça automatiquement. La norme utilisée, c'est le LUFS (Loudness Units Full Scale), qui est devenue le standard de l'industrie, et YouTube, Spotify, les TV... tout le monde utilise ça maintenant pour mesurer et normaliser le volume audio.
D'ailleurs, si vous débutez complètement avec cet outil, je vous conseille de jeter un œil à mon guide FFmpeg pour les nuls pour bien piger les bases de la ligne de commande.
Allez, c'est partiii ! Temps estimé : 2-5 minutes par fichier (selon la méthode choisie)
Mais, avant de se lancer dans les commandes, un petit point sur les paramètres qu'on va manipuler. Le filtre loudnorm utilise trois valeurs principales. D'abord I (Integrated loudness), c'est le volume moyen global mesuré en LUFS. La valeur standard pour le streaming, c'est -16 LUFS pour YouTube et Spotify, ou -23 LUFS pour la diffusion broadcast. Ensuite TP (True Peak), le niveau maximal que le signal ne doit jamais dépasser. On met généralement -1.5 dB pour avoir une marge de sécurité. Et enfin LRA (Loudness Range), qui définit la plage dynamique autorisée, généralement autour de 11 dB.
C'est la méthode la plus rapide, parfaite pour du traitement à la volée :
Connexionffmpeg -i entree.wav -af loudnorm=I=-16:TP=-1.5:LRA=11 -ar 48000 sortie.wav
Pourquoi ces valeurs : -16 LUFS c'est le standard YouTube/Spotify, -1.5 dB de true peak évite le clipping, et 11 dB de range dynamique garde un son naturel.
Le truc c'est que cette méthode fait une analyse en temps réel et ajuste à la volée. C'est bien, mais pas parfait. Pour un résultat vraiment précis, y'a mieux.
Cette méthode analyse d'abord le fichier complet, puis applique les corrections exactes. C'est plus long mais beaucoup plus précis.
Première passe, on analyse :
ffmpeg -i entree.wav -af loudnorm=I=-16:TP=-1.5:LRA=11:print_format=json -f null -
FFmpeg va vous sortir un bloc JSON avec les mesures du fichier (input_i, input_tp, input_lra, input_thresh). Notez-les bien, car vous allez les injecter dans la deuxième passe.
Deuxième passe, on applique avec les valeurs mesurées (remplacez les chiffres par ceux obtenus à l'étape précédente) :
ffmpeg -i entree.wav -af loudnorm=I=-16:TP=-1.5:LRA=11:measured_I=-24.35:measured_TP=-2.15:measured_LRA=8.54:measured_thresh=-35.21:offset=0:linear=true -ar 48000 sortie.wav
Pourquoi cette méthode ? En fait, en passant les valeurs mesurées, FFmpeg sait exactement de combien ajuster. L'option linear=true force une normalisation linéaire plutôt que dynamique, ce qui préserve mieux la dynamique originale.
Le principe est le même, on ajoute juste -c:v copy pour garder la vidéo intacte sans la ré-encoder :
ffmpeg -i video.mp4 -c:v copy -af loudnorm=I=-16:TP=-1.5:LRA=11 -ar 48000 video_normalise.mp4
D'ailleurs, pour ceux qui veulent automatiser ça à l'extrême, j'avais parlé de FFmpegfs , un système de fichiers qui transcode automatiquement ce que vous déposez dessus. C'est pratique si vous avez une grosse bibliothèque à gérer.
Si vous avez plein de fichiers à traiter, y'a un outil Python qui automatise la méthode dual-pass :
pip install ffmpeg-normalize
ffmpeg-normalize *.wav -o output_folder/ -c:a pcm_s16le
Cet outil fait automatiquement les deux passes et supporte le traitement parallèle. Pratique pour normaliser une bibliothèque entière.
Erreur "No such filter: loudnorm" : Votre version de FFmpeg est trop ancienne (il faut la 3.1 minimum). Mettez à jour votre binaire.
Le son est distordu après normalisation : Le fichier source était probablement déjà saturé. Essayez de baisser le target (-18 LUFS au lieu de -16) ou augmentez le headroom du true peak (-2 dB au lieu de -1.5).
Voilà, maintenant vous n'avez plus d'excuse pour avoir des niveaux audio qui varient dans tous les sens. Le LUFS c'est le standard, FFmpeg gère ça nativement, et ça prend 30 secondes.
Vos auditeurs vous remercieront.
C’est la dernière pièce manquante pour enterrer définitivement le SMS. La prochaine mise à jour de l’iPhone va introduire le RCS 3.0 avec du chiffrement de bout en bout. Les quatre principaux opérateurs français devraient être prêts au lancement.
Le 16 février 2026, la plateforme « Choisir le service public » a alerté par mail les personnes concernées par un incident de cybersécurité survenu au début du mois. Les données compromises révèlent beaucoup plus que les simples identités des usagers.
Le Premier ministre britannique Keir Starmer veut « limiter l’accès » des mineurs aux VPN. De fait, il faudra vérifier l'âge de tout le monde, car il est techniquement impossible de trier à l'avance les utilisateurs sans une preuve. Et la France est sur la même trajectoire.
Le CNRS vient de confirmer un incident de cybersécurité qui a mené au téléchargement non autorisé de fichiers contenant des données personnelles d'anciens agents. Noms, adresses, numéros de sécurité sociale, RIB : la totale donc. L'organisme a déposé plainte et prévenu la CNIL.
Des données très sensibles
C'est ce lundi 16 février que le CNRS a informé ses agents d'une fuite de données sur un de ses serveurs. Des fichiers contenant des informations de ressources humaines ont été téléchargés sans autorisation. Et on ne parle pas de données anodines : noms, prénoms, dates de naissance, adresses postales, numéros de sécurité sociale et RIB. Le tout accompagné du statut de l'agent, du type de contrat et de la structure d'affectation. Le serveur a été isolé et arrêté dès la découverte de l'incident, et l'organisme assure que la fuite ne s'est pas propagée au reste de ses infrastructures.
Qui est concerné ?
Seuls les personnels recrutés avant le 1er janvier 2007 sont touchés, qu'ils aient été titulaires ou non. Si vous avez travaillé au CNRS après cette date, vous n'êtes pas concerné. Le nombre exact de victimes n'a pas été communiqué, mais vu la taille de l'organisme, on parle potentiellement de plusieurs milliers de personnes. Le CNRS recommande de prévenir sa banque, de surveiller ses comptes, de vérifier si ses données circulent sur haveibeenpwned.com, et de rester vigilant face aux tentatives de phishing ou d'usurpation d'identité. La CNIL et l'ANSSI ont été prévenues, et une plainte a été déposée auprès de la section cybercriminalité du parquet de Paris.
Les institutions françaises en ligne de mire
On n'est pas vraiment sur une première niveau cyberattaques sur des services de l'état. Le ministère de l'Intérieur, celui des Sports, et d'autres organismes avaient été visés. L'URSSAF a aussi confirmé une fuite touchant les données de 12 millions de salariés. Le CNRS lui-même avait été la cible d'un défacement de plusieurs de ses sous-domaines fin janvier. Deux incidents distincts, mais la tendance est claire, et c'est franchement moche.
On va quand même saluer le fait que le CNRS a communiqué rapidement, avec un communiqué officiel et une FAQ pour les personnes concernées. C'est loin d'être toujours le cas. Mais on va quand même se questionner sur le fait que des RIB et des numéros de sécu trainent sur un serveur, alors qu'on parle de données parfois veilles depuis presque 20 ans... Pourquoi ces informations étaient-elles encore accessibles ? La question du stockage prolongé de données sensibles revient sur la table, et visiblement, personne n'a encore de bonne réponse. En attendant, si vous avez porté la blouse du CNRS avant 2007, un petit tour sur votre relevé bancaire ne serait pas du luxe.
Article invité publié par Vincent Lautier . Vous pouvez aussi faire un saut sur mon blog , ma page de recommandations Amazon , ou lire tous les tests que je publie dans la catégorie "Gadgets Tech" , comme cette liseuse Android de dingue ou ces AirTags pour Android !
Le Premier ministre britannique Keir Starmer veut « limiter l’accès » des mineurs aux VPN. De fait, il faudra vérifier l'âge de tout le monde, car il est techniquement impossible de trier à l'avance les utilisateurs sans une preuve. Et la France est sur la même trajectoire.
Dans un article publié le 14 février 2026, le média américain The Verge revient sur la découverte involontaire d'une faille de sécurité affectant les appareils de la marque chinoise DJI. En bidouillant son aspirateur connecté pour le piloter avec une manette PlayStation, un utilisateur a pu accéder à des données de milliers d'appareils à travers le monde.
