Nous utilisons des cookies pour améliorer votre expérience.

MacBidouille

News du mercredi 25 février

Consommation en Watts de CPU Apple Silicon

Voilà voilà voilà... Prenez le temps de digérer cela !

J'ai utilisé Mx Power Gadget créé par Fabrice Leyne, dont je vous avais précédemment parlé, pour mesurer la consommation de différents SoC d'Apple, avec la GPU principalement au repos.
Ces mesures ne concernent donc que la CPU + RAM, et ont été prises avec la CPU au taquet en utilisant PrimeSieve installé avec Homebrew.

D'abord on peut remarquer une augmentation régulière de la consommation électrique des entrée-de-gamme de chaque génération de SoC Mx d'Apple.
Au point d'ailleurs que si ça continue comme cela, le M6 pourrait consommer autant qu'un M1 Pro avec tous les problèmes qui se poseront sur MacBook Air M6 et même MacBook Pro 14" M6 !

Je compte refaire l'exercice avec CPU + GPU chacun au taquet, ça pourrait être pire ...

Ensuite, la CPU du M5 de base consomme 27% de plus que celle du M4 de base !
Tout cela pour 15% (annoncé) ou 19% (mesuré avec geekbench 6) de performances en plus.
Malgré le passage de la gravure TSMC "3nm" de la seconde à la troisième génération, l'efficacité énergétique est inférieure ! Une incroyable nouveauté et un énorme problème à venir !

En résumé, la génération M5 pourrait poser des problèmes de TDP dans certains Mac dont évidemment le futur MacBook Air M5, mais aussi avoir moins d'autonomie pratique que la génération M4 en réalisant le même travail.

Fichier national des comptes bancaires FICOBA des impôts piratés : mon point-de-vue de spécialiste de la sécurité

Le fichier national des comptes bancaires "FICOBA", géré par la Direction Générale des Finances publiques (DGFiP), a été piraté entre le 28 janvier 2026 et le 13 février 2026.

Environ 1,2 millions de comptes ont été accédés : les informations "[de votre] état-civil, de votre adresse postale et de vos coordonnées bancaires", d'après le ministère.

Ça a fait les manchettes, mais j'aimerais revenir sur ce qui c'est passé, car il y a de nombreux points intéressants dans la communication officielle. Notamment dans leur FAQ.

Les identifiants d'un fonctionnaire

Voilà le point d'entrée : les identifiants d'un fonctionnaire ont été "usurpés".
On peut légitimement se demander si il y avait un 2FA, une authentification à deux-facteurs dont TOTP2 ou FIDO2, ou même multifactorielle.

À ce niveau de sensibilité, de risque et d'impact, le minimum en sus d'un mot-de-passe fort c'est une clé physique FIDO2 et si possible une clé physique FIDO2 avec biométrie (capteur d'empreinte) inutilisable même si volée.

Ce que l'on sait : son mot-de-passe fort (souvent noté sur un post-it !)
Ce que l'on a : la clé physique FIDO2 unique
Ce que l'on est : son empreinte physique sur la clé pour l'activer

Un fonctionnaire et des usages très particuliers

Ce fonctionnaire avait des accès "dans le cadre de l’échange d’information entre ministères".
Cela signifie qu'il n'avait pas un usage encadré de la même manière que pour les consultations usuelle du fichier FICOBA, donc probablement pas les mêmes règles de sécurité et restrictions autour de son usage.

On peut tout de suite comprendre, via "dans le cadre de l’échange d’information entre ministères" et un usage qui est inhabituel, qu'il y à là, comme dans de nombreuses interconnexions de bases-de-données ou fichiers, une faille potentielle.

Ça renforce le point précédent, sur un usager qui est exceptionnel dans ses usages donc ses droits et les règles de sécurité qui s'appliquent : clé FIDO2 avec sécurité biométrique en sus du mot-de-passe fort.

Priorité à la sécurité des données et donc celle des Français

Priorité à la sécurisation des données, quitte à affecter les opérations, et c'est exactement ce qu'il faut faire dans un tel cas. Mettre fin à l'hémorragie ! Couper court !

Un DSO Officier de Sécurité des Données doit négocier cette autorité, et qu'elle soit connue de tous en interne mais aussi coté clients, fournisseurs et partenaires pour éviter tout "malentendu".
Le DSO a pleine autorité sur les données dont leur sécurité. Personne d'autre.

Prendre les bonnes décisions, le plus tôt possible. Excellent !

Communication

La Direction Générale des Finances publiques (DGFiP) va communiquer directement auprès de chaque Français touché.
C'est là aussi excellent, pour la communication, mais aussi car ça démontre un bon niveau de Log le permettant.

"La DGFiP a pour obligation d'informer dès qu'une consultation semble frauduleuse, conformément à l'article 34 du règlement général sur la protection des données (RGPD)."
Excellent là aussi, indiquer clairement le cadre légal et le respecter.

En conclusion

J'aime beaucoup la façon dont la DGFiP a réagit.
Pas de déclarations à l'emporte-pièce qui se révèlent fausses deux jours plus tard, pas de bruit, juste un audit interne basé sur des logs et donc une information concise, précise et correcte.

Arrêter l'hémorragie quitte à impacter ou bloquer les opérations : parfait, la sécurité avant tout !

Et une bonne communication individuelle auprès des Français touchés. Parfait aussi !

Les problèmes identifiés

Maintenant, il y a le problème des identifiants, qui laisse à penser que le niveau de sécurité n'est pas assez élevé pour cet utilisateur et ses usages. Probablement le même niveau pour tous...
Droits plus élevés, authentification plus stricte. Bien sûr rien n'est parfait !

Pas de suivi quotidien de cet utilisateur ayant des droits très différents, et une alerte après 1,2 millions de comptes accédés sur deux semaines. 1,2 millions de comptes ! Deux semaines !
Droits plus élevés, surveillance rapprochée.

Et le problème d'interconnexions de bases-de-données ou de fichiers, qui revient régulièrement parmi les facteurs ayant permis une attaque réussie. Un facteur souvent décisif.

On voudrait nous proposer ou imposer un "ID numérique" avec une tonne d'interconnexion de bases-de-données ou fichiers divers et variés, plus sensibles les uns que les autres ?!?

Sondage

Etes-vous tenté par le nouveau Mac mini M4 ?