Profitez de la version Podcast 😉

La Notarization, le nouveau gatekeeping invisible d’Apple

Apple vient d’introduire en décembre 2025 un système appelé « Notarization » pour la conformité à la loi japonaise (MSCA). Ce que les observateurs ont manqué, c’est que ce n’est pas une « ouverture » de l’écosystème, mais le blueprint d’un nouveau modèle de contrôle centralisé, plus subtil et réplicable que l’App Store classique.

Présenté comme une simple conformité réglementaire, ce système redéfinit en réalité la relation entre Apple, les développeurs et les régulateurs. C’est un pivot stratégique majeur qui préfigure la réaction d’Apple aux pressions réglementaires mondiales.

Pourquoi c’est structurel, pas cosmétique

À première vue, la Notarization semble moins intrusive que l’App Review traditionnel. Elle ne vérifie que quatre critères : fonctionnalité basique, absence de malware connu, absences de vulnérabilités évidentes, et vérification de l’identité du développeur.

Mais regardez l’architecture : toutes les apps, même celles distribuées via des marketplaces alternatives, passent par le filtre Apple. Aucune exception. C’est moins visible qu’une rejection d’App Store, mais c’est un point de contrôle obligatoire et non négociable.

Apple n’a pas perdu le veto final, elle l’a simplement caché derrière un écran de « sécurité basique ».

La différence avec l’Europe est révélatrice. En Europe, les apps peuvent être distribuées directement via website sans vérification Apple (sauf les PWA). Au Japon, même ce chemin est fermé : tout passe par la Notarization.

Apple a collaboré avec le régulateur japonais (pas d’approche « adversariale » comme en Europe), ce qui lui permet de garder le contrôle tout en paraissant conforme.

Comment ça marche techniquement

La Notarization combine des vérifications automatisées et une revue humaine. Les critères publics sont minimalistes : malware, crashes, comportements malveillants détectables.

Mais voici l’intéressant : Apple signe et chiffre toutes les apps notarizées, puis effectue des vérifications lors de l’installation pour s’assurer qu’aucune falsification/attaque n’a eu lieu. C’est un nouveau point de contrôle en runtime, pas seulement à la distribution.

Cette architecture crée un précédent technique. Apple peut, à tout moment, ajouter des critères de vérification automatisée sans modifier le framework public. Les critères peuvent évoluer discrètement, sans grand bruit réglementaire.

Vers quelle mutation cela pointe-t-il ?

À 18 mois, cet approche sera probablement étendue à d’autres marchés sous pression (UK, potentiellement les US si des lois de type DMA arrivent). Apple bascule d’une stratégie « gatekeeping par monopole » à une stratégie « gatekeeping par certification ».

C’est plus malin : au lieu de dire « vous ne pouvez pas distribuer », Apple dit « vous pouvez distribuer si vous passez notre certification de sécurité ». La compliance paraît équitable. Mais le résultat final est identique : Apple reste arbitre ultime.

Pour les développeurs, cela signifie deux choses. Première, une App Review moins rigoureuse (car plus focalisée). Deuxième, une Notarization qui s’étendra à tous les OS Apple dans tous les marchés régulés.

Conséquence ?

À court terme, aucun changement visible. Les apps notarizées arriveront probablement plus vite en Japon, et les prix baisseront (5% de commission vs 30%).

À moyen terme, le modèle s’étendra. Tous les OS Apple (macOS, iOS, iPad OS) adopteront probablement une Notarization locale, adaptée aux régulations locales.

À long terme, c’est une réimagination de la relation entre Apple et ses développeurs. Moins de dictature visible, plus de « compliance par certification ». Moins d’App Store review publiquement controversée, plus de filtres techniques discrets mais tout aussi efficaces.

L’utilisateur pro n’est pas impacté directement. Mais son univers de développement, les tools qu’il peut installer, les frameworks qu’il peut utiliser, les designs qu’il peut implémenter, reste sous le contrôle apple, juste sous une nouvelle couche de légitimité réglementaire.

Tableau des sources

Vous avez une question, une idée ou une remarque ?
Je serai ravi de vous lire ! ✉️ henrido@hdrapin.com

La version Podcast pour vos oreilles 😉

L’architecture vulnérable se révèle par la spéculation !

En janvier 2025, des chercheurs de Georgia Tech et Ruhr University ont publié des preuves de concepts d’attaques côté canal ciblant un mécanisme de prédiction d’adresses mémoire dans les processeurs Apple Silicon.

Ces vulnérabilités nommées SLAP (Data Speculation via Load Address Prediction) et FLOP (False Load Output Predictions) exposent une faille structurelle ignorée des annonces officielles d’Apple, affectant les générations M2, M3, A15, A17 et potentiellement les puces suivantes.

Ce que personne n’a remarqué

La mutation est invisible car Apple a construit ces prédicteurs (LAP et LVP) pour maximiser les performances, sans annoncer les compromis de sécurité inhérents. Ces attaques ne demandent pas de patchs du système d’exploitation, elles contournent les mécanismes de sécurité au niveau du silicium lui-même. C’est un problème matériel qui ne peut être résolu que par un redesign ou des limitations de performance.

La prédiction d’adresses mémoire et de valeurs est une technique standard pour accélérer les processeurs, mais Apple n’a jamais documenté les risques de spéculation associés. Les chercheurs ont démontré qu’en forçant des mauvaises prédictions, ils récupéraient des données sensibles comme des contenus d’e-mails ou l’historique de navigation Safari.

Anatomie technique de l’exploit

Le Load Address Predictor (LAP) prédit quelle adresse mémoire le processeur va consulter selon les patterns d’accès antérieurs. Quand cette prédiction échoue, le processeur effectue du travail spéculatif sur des données arbitraires hors limites. Ces mispredictions laissent des traces dans l’état microarchitectural du CPU et dans le cache, traces que les attaquants peuvent observer et exploiter pour reconstituer les données.

FLOP fonctionne de manière analogue sur le Load Value Predictor (LVP) introduit avec les M3/A17, qui prédit la valeur des données plutôt que l’adresse. L’attaque peut être lancée depuis un site web malveillant, sans accès physique à l’appareil. Un utilisateur naviguant innocemment devient vecteur de compromission.

Conséquences logiques pour les six prochains mois

Apple ne peut patcher cela via des mises à jour logicielles standard. Les options sont limitées et toutes problématiques.

• Soit réduire les performances en désactivant partiellement ces prédicteurs (impensable commercialement),
• soit accepter le risque et documenter les limitations,
• soit concevoir une nouvelle génération de silicium avec isolation supplémentaire.

L’absence de patchs officiels malgré cinq mois écoulés indique qu’Apple choisit probablement l’option trois : laisser cette génération vulnérable et intégrer des mitigations matérielles dans les M4 et futurs processeurs.

Cela signifie que les M2 et M3 resteront exposés. Pour les utilisateurs pro, c’est une faille de confiance majeure dans la sécurité du silicium fondateur.

Tableau de Référence

Vous avez une question, une idée ou une remarque ?
Je serai ravi de vous lire ! ✉️ henrido@hdrapin.com