La police peut-elle déverrouiller un téléphone saisi ? iPhone, Android : l'état réel en 2026

il y a 4 jours

39 min de lecture

Mis à jour le 18 octobre 2026.

Votre téléphone a été saisi, ou vous craignez qu'il le soit. Vous vous demandez ce que la police pourra en tirer : vos messages, ceux que vous avez effacés, vos photos, WhatsApp. La réponse courte, qu'il s'agisse de « ils ouvrent tout » ou de « un iPhone est inviolable », est fausse dans les deux sens. Trois choses décident : votre téléphone était-il allumé au moment où il a été pris, quel est son âge et quelle puce il contient, et combien de caractères compte votre code. Selon la combinaison, la police obtient la quasi-totalité du contenu, une petite fraction, ou rien du tout. Vous trouverez ici, modèle par modèle, ce que les outils réellement utilisés en Belgique parviennent à faire, ce qu'ils ne font pas, ce que leurs fabricants annoncent sans le prouver — et pourquoi un téléphone saisi le vendredi n'est plus le même appareil le lundi. Chaque affirmation porte sa source. Si vous êtes pressé, les deux tableaux de synthèse suffisent.

En octobre 2026, la police belge parvient à lire les données d'un smartphone dont le propriétaire refuse le code dans une grande partie des cas, mais pas dans tous ; et la ligne de partage ne sépare pas Android d'Apple. Elle sépare trois situations.

Premièrement, l'état du téléphone à la saisie : allumé et déjà déverrouillé une fois depuis le démarrage (« AFU »), il livre la plupart de ses données aux outils Cellebrite ou GrayKey, souvent sans que le code soit jamais retrouvé ; éteint ou redémarré (« BFU »), il ne livre qu'une fraction, sauf à casser le code (Zinkus, Jois, Green, Johns Hopkins, 2021).

Deuxièmement, l'âge et le matériel : les iPhone jusqu'au modèle X (2017) et la quasi-totalité des Android bon marché à puce MediaTek ou Unisoc ont des failles matérielles incorrigibles qui les exposent même éteints, alors que les iPhone 12 et suivants et les Google Pixel 6 et suivants ne sont pas, à ce jour, documentés comme « cassables » en force brute lorsqu'ils sont éteints (Elcomsoft, checkm8, mars 2024 ; GrapheneOS, lecture de la documentation Cellebrite de janvier 2025).

Troisièmement, le code lui-même : court et numérique, il tombe ; long et alphanumérique, il reste hors de portée.

Depuis fin 2024, Apple (iOS 18.1) et, en option, Google (Android 16) font redémarrer un téléphone resté verrouillé 72 heures, ce qui le ramène dans l'état le plus résistant et transforme la saisie en course contre la montre (Jiska Classen, nov. 2024). En Belgique, l'outil dominant est Cellebrite (au moins 39 zones flamandes, contrat interzonal d'Anvers, police fédérale) ; la Douane utilise GrayKey depuis 2024 ; les appareils que les zones locales n'ouvrent pas remontent vers la FCCU et les RCCU fédérales, avec des délais que les zones qualifient elles-mêmes de longs (VRT NWS, 8 août 2025).

Le cadre légal, lui, est stable : le refus du code est punissable (article 88quater du Code d'instruction criminelle, Cass. 4 février 2020, Cour constitutionnelle n° 28/2020), la loi de mise en concordance de 2026 n'a fait que déplacer la peine dans le nouveau Code pénal, et la Cour européenne des droits de l'homme a validé le modèle français voisin en mai 2026 (Minteh c. France).

Résumé en dix points

L'état à la saisie décide de presque tout. Un téléphone saisi allumé et déverrouillé au moins une fois depuis le démarrage (« AFU », After First Unlock) garde ses clés de chiffrement en mémoire ; un téléphone éteint ou redémarré (« BFU », Before First Unlock) ne les a pas. En AFU, les outils extraient la majorité des données sans connaître le code ; en BFU, ils n'obtiennent qu'une fraction, sauf à casser le code (Johns Hopkins, 2021 ; Jiska Classen, 2024).
Le code ne peut être essayé que sur le téléphone lui-même, à environ 80 millisecondes par essai sur iPhone, avec des pauses imposées par une puce dédiée, la Secure Enclave. Toute force brute sérieuse suppose d'abord une faille qui neutralise ces pauses (Apple Platform Security).
Anciens iPhone (5s à X, 2013-2017) : vulnérables à vie. La faille matérielle « checkm8 » ne se corrige pas par mise à jour. Elle donne une extraction partielle en BFU et complète en AFU, mais pas la force brute du code sur les modèles dotés d'une Secure Enclave (Elcomsoft, 2022).
iPhone XR, XS et 11 (2018-2019) : force brute documentée jusqu'à iOS 17.3.1 dans les matrices Cellebrite fuitées d'avril 2024 ; GrayKey annonçait encore un accès « complet » sur iPhone 11 sous iOS 18.0 en novembre 2024 (MacRumors ; 3DNews).
iPhone 12 à 17 : aucune preuve publique de force brute en BFU. Les fuites de 2024-2025 ne montrent qu'un accès « partiel » (GrayKey) ou un appareil éteint « généralement » inaccessible (lecture GrapheneOS de la documentation Cellebrite). Les annonces 2026 de Cellebrite (« AFU and BFU », iPhone 17, iOS 26.3.1) sont du marketing non vérifié (404 Media, nov. 2024 ; Cellebrite, mai 2026).
Android : la puce fait la différence, pas la version. Les téléphones MediaTek et Unisoc (Xiaomi/Redmi, Oppo, Realme, Samsung série A bas de gamme) ont des failles de démarrage incorrigibles et un verrouillage contournable : la force brute se fait « hors ligne », sans limite d'essais. Les Pixel 6 à 9 (puce Titan M2) ne sont pas brute-forçables éteints d'après toutes les fuites ; les Samsung récents restent couverts par au moins un vendeur et ont été ouverts en Serbie par Cellebrite fin 2024 (Osservatorio Nessuno, mai 2026 ; Amnesty, fév. 2025).
Le redémarrage automatique à 72 heures change la logistique. iOS 18.1 (octobre 2024) et Android 16 avec Advanced Protection (optionnel) ramènent un téléphone resté verrouillé trois jours en état BFU. Un téléphone saisi le vendredi et branché le lundi peut déjà avoir basculé. Les modes « GrayKey Preserve » et « Safeguard Mode » prétendent figer l'état AFU ; la méthode n'est pas vérifiée indépendamment (Magnet, nov. 2024 ; TechSpot, oct. 2026).
Un code long et non numérique reste la protection décisive. Avec un exploit en place, un code à 4 chiffres tombe en minutes et un code à 6 chiffres en heures à jours (estimations 2018) ; en 2023, le mode le plus rapide de Cellebrite plafonnait, selon un concurrent, à environ 5 000 essais par jour, soit des mois pour un code à 6 chiffres aléatoire. Un mot de passe alphanumérique long est hors de portée (Elcomsoft, 2023).
En Belgique, Cellebrite est partout, GrayKey est à la Douane, et le fédéral a des délais. Licences locales de 7 200 à 19 000 euros par an, « déverrouillages illimités » via le contrat d'Anvers, 17 téléphones ouverts par la Douane en deux ans avec GrayKey. Les appareils que le niveau local n'ouvre pas partent vers la police fédérale (FCCU/RCCU), en sous-effectif reconnu (PV Lanaken-Maasmechelen, mars 2024 ; VRT NWS, 5 mars 2026).
Quand le téléphone résiste, les enquêteurs vont ailleurs : cloud Apple (mais Apple n'a fourni aucun contenu à la Belgique au second semestre 2024), compte Google, opérateurs, ordinateur appairé, et depuis le 18 août 2026 les injonctions européennes e-Evidence. Le droit belge reste celui de 2020 : refus de code punissable, mais à deux conditions, l'appareil trouvé sans contrainte sur la personne et la connaissance du code prouvée au-delà de tout doute raisonnable (Apple Transparency 2024 H2 ; UCLouvain, Cass. 4 fév. 2020 et note Forget).

Comment fonctionne le verrouillage d'un smartphone

Le code n'ouvre pas une porte, il fabrique une clé

Sur un smartphone moderne, les données ne sont pas rangées derrière le code comme derrière une serrure. Elles sont chiffrées, c'est-à-dire rendues illisibles par un calcul mathématique. La clé qui permet de les relire est fabriquée à partir de deux éléments combinés : le code de l'utilisateur et une clé matérielle unique gravée dans le processeur à la fabrication. Apple appelle cette clé matérielle l'« UID ». Elle n'est jamais lisible par logiciel, ni par Apple ni par ses fournisseurs. La conséquence est capitale : on ne peut pas copier les données sur un gros ordinateur pour y essayer des millions de codes à grande vitesse. Chaque essai doit passer par le téléphone lui-même. Apple calibre le calcul pour qu'un essai prenne environ 80 millisecondes (Apple, Passcodes and passwords).

La Secure Enclave et la limitation des essais

Sur iPhone, ce calcul se fait dans un petit processeur séparé, la Secure Enclave (« enclave sécurisée »), présente depuis l'iPhone 5s (2013). C'est elle qui compte les essais et impose des pauses. Apple publie le barème : aucune pause pour les trois premiers essais, puis 1 minute au quatrième, 5 minutes au cinquième, 15 minutes au sixième, 1 heure au septième, 3 heures au huitième, 8 heures au neuvième ; au dixième, l'appareil se bloque jusqu'à connexion à un ordinateur. Redémarrer le téléphone n'efface pas la pause en cours. Si l'option « Effacer les données » est activée, dix essais faux consécutifs effacent le contenu (Apple, Passcodes and passwords). Les iPhone 5 et 5c, qui n'ont pas de Secure Enclave, gèrent ces pauses par logiciel, ce qui permet de les désactiver : un outil mesure alors 13,6 essais par seconde, soit environ 21 heures pour parcourir tous les codes à 6 chiffres (Elcomsoft, 2020).

Sur Android, l'équivalent s'appelle Gatekeeper (ou Weaver), un module qui vérifie le code et impose les pauses. Il tourne soit dans une zone protégée du processeur principal, le TEE (Trusted Execution Environment, « environnement d'exécution de confiance », par exemple TrustZone chez Qualcomm), soit dans une puce physiquement séparée appelée élément sécurisé (Titan M2 sur les Pixel 6 et suivants, Knox Vault sur certains Samsung). La documentation Android décrit un barème comparable : pauses croissantes dès le cinquième échec, 4 heures au dixième, 4 jours au treizième, et plus aucun essai possible à partir du vingtième dans les versions récentes (AOSP, Rate limiting). La différence entre TEE et élément sécurisé est au cœur de tout ce qui suit : un TEE partage le processeur principal et ses failles ; un élément sécurisé est une puce à part, bien plus difficile à attaquer.

FDE et FBE : deux générations de chiffrement Android

Jusqu'à Android 6, le chiffrement Android était du FDE (Full Disk Encryption, chiffrement du disque entier) : une seule clé pour toute la mémoire, parfois dérivée d'un code par défaut si l'utilisateur n'avait pas activé le « démarrage sécurisé ». Depuis Android 7, et obligatoirement pour tout appareil lancé sous Android 10 ou plus, c'est le FBE (File-Based Encryption, chiffrement par fichier) : chaque fichier a sa propre clé, et les fichiers sont rangés en deux catégories. Le stockage « CE » (Credential Encrypted) n'est lisible qu'après le premier déverrouillage ; le stockage « DE » (Device Encrypted) est lisible dès le démarrage (AOSP, File-based encryption). Sur iOS, le même principe existe sous forme de classes de protection : la classe A (Complete Protection), dont la clé disparaît de la mémoire dix secondes après le verrouillage ; la classe C (Protected Until First User Authentication), dont la clé reste en mémoire tant que le téléphone est allumé ; et la classe D, protégée seulement par la clé matérielle. La classe C est celle par défaut des applications tierces, ce qui explique pourquoi un téléphone allumé en livre tant (Apple, Data Protection classes).

BFU et AFU : la distinction qui gouverne la pratique

BFU (Before First Unlock, « avant le premier déverrouillage ») désigne un téléphone allumé mais jamais déverrouillé depuis son dernier démarrage, ou éteint. Les clés dérivées du code n'ont jamais été calculées : la reconnaissance faciale ne fonctionne pas, les mots de passe Wi-Fi sont inaccessibles, les noms des contacts n'apparaissent pas dans les notifications. AFU (After First Unlock, « après le premier déverrouillage ») désigne un téléphone déverrouillé au moins une fois depuis le démarrage, puis reverrouillé. Les clés sont alors en mémoire vive et y restent tant que l'appareil est alimenté (Jiska Classen, 2024).

L'étude de référence de l'université Johns Hopkins constate que les téléphones sont « le plus souvent » saisis en AFU, et qu'une « surprising amount » de données sensibles des applications intégrées d'Apple utilise la classe la plus faible, de sorte que la majeure partie est accessible depuis un téléphone allumé et verrouillé dès lors qu'un outil y obtient une exécution de code. Sur Android, la même étude note qu'il n'existe « no equivalent of Apple's Complete Protection » : une fois le premier déverrouillage passé, les clés restent en mémoire en permanence (Zinkus, Jois, Green, 2021).

Les quatre niveaux d'extraction

Les laboratoires distinguent l'extraction logique (ce que le téléphone accepte de livrer à un ordinateur, comme une sauvegarde), l'extraction full file system (abrégée FFS, copie complète du système de fichiers déchiffré, qui suppose le téléphone déverrouillé ou compromis), l'extraction physique (image brute de la mémoire, lisible seulement si l'on a les clés) et le chip-off ou JTAG (dessouder la puce mémoire ou se brancher sur les points de test de la carte). Le guide américain NIST décrit le chip-off comme une opération exigeant une formation étendue et comportant un risque de détruire la puce (NIST SP 800-101r1). Sur un appareil moderne dont le chiffrement est lié au matériel, le chip-off seul ne donne qu'une mémoire chiffrée ; aucune source consultée ne revendique un chip-off produisant des données en clair sur un Android 10 ou plus.

Force brute et exploits

« Force brute » (brute force) signifie essayer tous les codes possibles. Un code à 4 chiffres a 10 000 combinaisons, un code à 6 chiffres un million. Sur un téléphone sain, le barème des pauses rend la force brute impossible. Les outils forensiques doivent donc d'abord obtenir une exécution de code sur le téléphone grâce à une faille (un « exploit ») qui désactive ou contourne les pauses. Le glossaire des documents Cellebrite fuités le résume en une ligne : « BF: Brute Force password after BFU exploitation » ; et GrapheneOS précise que ce BF « implies bypassing random 6-digit PINs. It does not imply bypassing a decent passphrase » (GrapheneOS forum).

checkm8 : l'exemple de la faille incorrigible

checkm8 (2019) est une faille dans la « bootrom », le tout premier programme exécuté par la puce, gravé en usine. Elle touche les processeurs Apple A5 à A11, c'est-à-dire de l'iPhone 4S à l'iPhone X. Comme la bootrom n'est pas modifiable, aucune mise à jour iOS ne la corrige. Elcomsoft la qualifie de « the best and most forensically sound method for devices with a bootloader vulnerability » (Elcomsoft, mars 2024). Côté Android, les puces MediaTek ont des failles de bootrom équivalentes, exploitées par l'outil libre mtkclient ; Osservatorio Nessuno les qualifie d'« unpatchable » et juge ces appareils « effectively unmitigable against BFU attacks » (Osservatorio Nessuno, mai 2026).

Deux barrières supplémentaires : le port USB et le mode Isolement

Depuis iOS 11.4.1, l'USB Restricted Mode (mode restreint USB) coupe les connexions de données par le port de charge une heure après le verrouillage, ou immédiatement si aucun accessoire n'a été branché depuis trois jours ; le téléphone continue de charger mais ne communique plus avec un ordinateur tant qu'il n'est pas déverrouillé (Apple, Activating data connections securely). Le mode Isolement (Lockdown Mode, depuis iOS 16) va plus loin : l'iPhone doit être déverrouillé pour se connecter à tout accessoire ou ordinateur (Apple, About Lockdown Mode). Ces barrières visent précisément le câble par lequel Cellebrite et GrayKey travaillent. Apple a corrigé en février 2025 (iOS 18.3.1) une faille permettant « a physical attack [to] disable USB Restricted Mode on a locked device », exploitée selon Apple « in an extremely sophisticated attack » (Apple, iOS 18.3.1 ; Quarkslab).

iPhone : ce qui est possible selon la génération et la version d'iOS

Jusqu'à l'iPhone X : checkm8 et la force brute sur les plus anciens

Les iPhone 5 et 5c (processeur A6, sans Secure Enclave) sont les seuls où la force brute complète est documentée sans réserve : 13,6 essais par seconde, 21 heures au plus pour un code à 6 chiffres (Elcomsoft, 2020). Pour les iPhone 5s à X (processeurs A7 à A11), checkm8 permet une extraction BFU partielle quelle que soit la version iOS : liste des applications, historique Wi-Fi, fichiers média, notifications (qui peuvent contenir des extraits de messages), points de localisation et messagerie vocale, mais pas les messages eux-mêmes ni la plupart du trousseau, chiffrés avec une clé dérivée du code. Sur un iPhone X de test sous iOS 12.4, environ 45 Go sur 150 Go étaient lisibles. Cette extraction fonctionne aussi sur un appareil « désactivé » après dix essais (Elcomsoft, déc. 2019).

La force brute du code, en revanche, n'est supportée par cet outil que sur les appareils sans Secure Enclave, soit les iPhone 4 à 5c (Elcomsoft, sept. 2022). Cellebrite, lui, annonce dans ses notes de version la force brute sur iPhone 5s et 6 sous iOS 12.5.x et sur iPhone 6s, 7 et SE de 1re génération sous iOS 15.8.x ; c'est une affirmation de vendeur (Cellebrite, Inseyets 10.0).

Une nuance importante pour l'iPhone 8, 8 Plus et X : depuis iOS 16, la Secure Enclave désactive les clés nécessaires en mode de récupération si un code a déjà été défini sur l'appareil, de sorte que checkm8 ne donne plus accès aux données ; Elcomsoft écrit que l'extraction « can only be performed if the device has never had a passcode set » (Elcomsoft, news 858). Un vieil iPhone maintenu à jour n'est donc pas toujours un iPhone ouvert.

iPhone XR, XS, 11 et SE 2 (A12-A13) : la dernière génération brute-forçable

Les documents « Cellebrite iOS Support Matrix » d'avril 2024, dont Cellebrite a confirmé l'authenticité, montrent que tous les modèles listés étaient déverrouillables jusqu'à iOS 17.0.3 ; que sous iOS 17.1 à 17.3.1 seuls les iPhone XR, XS et 11 étaient supportés pour la force brute (capacité nommée « Supersonic BF ») ; et que sous iOS 17.4 et plus, tous les modèles étaient « In Research » (404 Media, 17 juillet 2024 ; AppleInsider ; Next.ink).

Les notes de version officielles contemporaines (UFED 7.68) confirment un brute force annoncé pour XS, XS Max, XR et SE 2 sous iOS 17.2 à 17.2.1 (Cellebrite). Les documents GrayKey fuités en novembre 2024 donnent un accès « full » à l'iPhone 11 sous iOS 18.0 et 18.0.1, alors que les modèles plus récents n'ont que « partial » (3DNews, 20 nov. 2024 ; MacTrast). GrapheneOS, qui détient des versions ultérieures de la documentation Cellebrite, résume : Cellebrite peut contourner entièrement l'élément sécurisé sur les appareils antérieurs à l'iPhone 12, mais « only partially bypass it on iPhone 12 or later » (GrapheneOS forum).

iPhone 12 à 15 (A14-A17) : accès AFU oui, force brute en BFU non documentée

Pour cette génération, les matrices d'avril 2024 indiquaient « Coming soon » (iPhone 12 à 14) et « In research » (iPhone 15) sous iOS 17.1 à 17.3.1, et seules des données limitées pouvaient être exportées (Next.ink). En novembre 2024, GrayKey ne proposait qu'un accès « partial » aux iPhone 12 à 16 sous iOS 18.0 et 18.0.1, et rien pour iOS 18.1 (404 Media, 19 nov. 2024). Le sens de « partial » n'est pas défini dans les documents ; la presse spécialisée l'interprète comme les fichiers non chiffrés et les métadonnées, par exemple la structure des dossiers et les tailles (Heise).

GrapheneOS, lisant la documentation Cellebrite de janvier 2025 qu'il n'a pas publiée, indique que l'accès à un appareil éteint n'est « generally » pas possible sur « an iPhone 12 or later », et que cela reste « still the case » dans ce document ; en revanche, Cellebrite suit les nouvelles versions iOS pour l'accès AFU avec « a couple months of delay » (GrapheneOS forum, page 6). Ces lectures de GrapheneOS sont des déclarations d'un tiers sur un document non public.

iPhone 16 et 17 (A18-A19), iOS 18 et iOS 26 : uniquement des affirmations de vendeurs

Aucun document fuité, mandat ou jugement public ne documente une force brute réussie sur un iPhone 16 ou 17. Les seules sources sont commerciales. Cellebrite annonce en mars 2026 le support « for the latest iOS version 26.3.1 » et de l'iPhone 17, l'accès AFU aux derniers iOS étant réservé à son service en laboratoire, Cellebrite Advanced Services (CAS) (Cellebrite, Spring 2026). Son billet du 29 mai 2026 parle de « covering the latest iOS (AFU and BFU) » sans citer de modèle ni de version, et qualifie la force brute d'« increasingly impractical » sur les téléphones modernes (Cellebrite, 29 mai 2026).

Magnet annonce le support d'iOS 26 pour GrayKey dès le jour de sortie, sans détail (Magnet, 1er oct. 2025). Elcomsoft, plus transparent, indique en avril 2026 que son extraction de bas niveau couvre iOS 17 et 18 jusqu'à 18.7.1 sur iPhone 8 à 16, mais seulement avec le code connu, que l'exploit iPhone 16 est « less stable », et qu'iOS 26 n'est couvert que par extraction logique (Elcomsoft, avril 2026). Un « accès BFU » annoncé par un vendeur peut désigner une extraction partielle d'un appareil éteint, et non le déverrouillage ; la formule « AFU and BFU » de 2026 doit donc se lire avec cette réserve.

L'iPhone 17 apporte en outre une nouveauté matérielle absente des générations précédentes. Apple a présenté en septembre 2025, avec les puces A19, la Memory Integrity Enforcement : une protection de la mémoire active en permanence, que la société décrit comme dirigée contre les chaînes d'exploitation employées par les logiciels espions commerciaux (The Hacker News, 9 septembre 2025). Apple ne la présente pas comme une protection contre les outils forensiques, et aucune source publique ne documente son effet sur eux. Mais ces outils reposent précisément sur des corruptions de mémoire. Il est raisonnable d'en attendre un allongement du délai entre la sortie d'une version d'iOS et son exploitation, sans qu'il soit possible de le chiffrer.

iOS 18.1 et le redémarrage d'inactivité

Depuis iOS 18.1 (28 octobre 2024), la Secure Enclave mesure le temps écoulé depuis le dernier déverrouillage et, au-delà de trois jours (la valeur de 259 200 secondes a été trouvée dans son code), ordonne un redémarrage qui ramène l'appareil en BFU. Ni la charge ni le réseau n'y changent rien. Jiska Classen, qui a analysé le mécanisme, conclut : « An attacker must have kernel code execution to prevent an inactivity reboot » (Jiska Classen, nov. 2024). Le phénomène a été révélé par un mémo de policiers de Detroit, surpris de voir des iPhone stockés pour examen redémarrer seuls (404 Media, 7 nov. 2024).

Magnet reconnaît le minuteur, conseille d'imager « dès que possible », et indique que le redémarrage se repère par le message « Face ID requires your passcode when iPhone restarts » et dans le fichier shutdown.log (Magnet, 13 nov. 2024). Les vendeurs ont répondu par des modes de préservation : « GrayKey Preserve » et un « Evidence Preservation Mode » (vidéo de formation Magnet du début 2025, révélée le 1er octobre 2026) dans lesquels un employé affirme que « the AFU state is not lost » même après redémarrage, et « Safeguard Mode » chez Cellebrite (mars 2026). La méthode n'est pas expliquée ; Classen suppose une manipulation de l'horloge interne ou un blocage des tâches d'expiration, et parle d'un « game changer » ; ni Magnet ni Apple n'ont commenté (TechSpot, 2 oct. 2026 ; Cellebrite Spring 2026). Si ces affirmations sont exactes, elles impliquent que l'outil a pris le contrôle avant le redémarrage, donc dans les 72 heures suivant le dernier déverrouillage.

Tableau de synthèse iPhone (état au 18 octobre 2026)

Génération / puce	Modèles	Saisi éteint ou redémarré (BFU), code inconnu	Saisi allumé et déverrouillé (AFU), code inconnu	Preuve et date
A6, sans Secure Enclave	iPhone 5, 5c	Force brute complète, 13,6 essais/s, environ 21 h pour 6 chiffres	Idem	Elcomsoft, août 2020 (blog vendeur, mesuré)
A7-A10 (checkm8)	5s, 6, 6s, 7, SE 1	Extraction BFU partielle permanente, toute version iOS ; force brute annoncée par Cellebrite (5s/6 sous iOS 12.5.x ; 6s/7/SE 1 sous iOS 15.8.x)	Extraction FFS complète via checkm8	Elcomsoft 2019-2022 (vérifié) ; Cellebrite notes de version 2024 (vendeur)
A11 (checkm8)	8, 8 Plus, X	Extraction BFU via checkm8 jusqu’à iOS 15.7 ; sous iOS 16 et plus, bloquée si un code a déjà été défini	FFS via checkm8 ; extraction agent (code requis) jusqu’à iOS 18.7.1	Elcomsoft 2022-2026 (vérifié)
A12-A13	XR, XS, 11, SE 2	Force brute Cellebrite jusqu’à iOS 17.0.3 (tous), 17.1-17.3.1 (XR, XS, 11, « Supersonic BF ») ; iOS 17.4 et plus « In Research » en avril 2024 ; GrayKey « full » iPhone 11 sous iOS 18.0/18.0.1	AFU supporté	Matrices Cellebrite avril 2024 (fuite authentifiée) ; GrayKey nov. 2024 (fuite)
A14-A17	12, 13, 14, 15, SE 3	Avril 2024 : « Coming soon » ou « In research » ; GrayKey « partial » sous iOS 18.0/18.0.1 ; appareil éteint « generally » inaccessible selon la documentation de janvier 2025 (lecture GrapheneOS)	AFU rattrapé à chaque version avec quelques mois de délai (GrapheneOS) ; CAS AFU iOS 26 et plus (Cellebrite 2026)	Fuites 2024 (vérifiées) ; GrapheneOS 2025 (tiers) ; Cellebrite 2026 (vendeur)
A18	16, 16 Pro, 16e	Aucune preuve publique ; GrayKey « partial » iOS 18.0/18.0.1	AFU revendiqué par les vendeurs 2025-2026	GrayKey nov. 2024 (fuite) ; Cellebrite et Magnet (vendeur)
A19	17, 17 Pro, Air, 17e	Aucune preuve publique ; « full support iPhone 17 / iOS 26.3.1 » sans détail BFU	CAS « AFU access iOS 26+ » ; Magnet « support iOS 26 » dès le 15 sept. 2025	Vendeurs uniquement

Facteurs transversaux : retour forcé en BFU après 72 h sans déverrouillage (iOS 18.1 et suivants) ; USB Restricted Mode (1 h, ou 3 jours sans accessoire) et correctif iOS 18.3.1 du 10 février 2025 ; mode Isolement (iOS 16 et suivants) ; code alphanumérique long hors de portée même avec un exploit.

Android : ce qui est possible selon la puce, la marque et la version

Android 5 à 9 : chiffrement du disque entier et bootloaders « déchiffrants »

Les Android anciens sont les plus simples à ouvrir. Sous Android 5.x, Cellebrite annonçait dès 2015 une « bootloader method » contournant le verrouillage sur 85 appareils Samsung (Galaxy S3 à S5, Note 3 et 4) (Forensic Focus, UFED 4.4, 2015). En 2019, UFED 7.23 revendiquait des extractions physiques avec contournement du verrouillage via un « Samsung Exynos decrypting bootloader » sur Galaxy S9 et des dizaines de modèles des séries A et J jusqu'à Android 9 (Cellebrite, Exynos).

Oxygen Forensic décrit pour environ 121 appareils Exynos (Android 7 à 9) une attaque en mode ODIN avant le chargement du système, avec un dictionnaire de 10 000 mots de passe courants parcouru en environ 40 minutes (Forensic Focus / Oxygen, 2021). Point important pour les anciens Samsung en FDE : si l'option « Secure Startup » n'était pas activée, « user credentials are not actually required to decrypt the data » une fois la mémoire lue (Osservatorio Nessuno, mars 2025). Ces capacités sont des revendications de vendeurs, mais elles sont anciennes, convergentes, et portent sur des appareils aujourd'hui sans support de sécurité.

Android 10 et plus (FBE) : la puce décide

Avec le chiffrement par fichier obligatoire, lire la mémoire ne suffit plus : il faut aussi la clé, dérivée du code et protégée par Gatekeeper dans le TEE ou l'élément sécurisé. Tout se joue alors sur la robustesse de cette protection. Un exploit du TEE ou du démarrage sécurisé, selon Osservatorio Nessuno, « could allow for offline bruteforcing », rendant « numerical PINs under 10 digits useless » (Osservatorio Nessuno, mars 2025). « Hors ligne » veut dire que l'attaquant, ayant contourné le compteur, essaie les codes sans subir les pauses ni la limite d'essais ; Belkasoft affirme que son attaque « runs offline, avoiding Android's throttling and attempt limits » sur certains MediaTek, Kirin et Unisoc (Belkasoft).

MediaTek et Unisoc : les téléphones bon marché, incorrigibles

C'est la catégorie la plus exposée, et la plus répandue dans le bas et le milieu de gamme (Xiaomi/Redmi, Oppo, Vivo, Realme, Alcatel, Nokia, ZTE, et les Samsung série A d'entrée de gamme). Les puces MediaTek ont des failles de bootrom exploitées par l'outil mtkclient et jugées « unpatchable » ; une preuve de concept de Quarkslab sur un Samsung A22 (puces MT6769V et MT6833V) montre la désactivation de la vérification du système, la désactivation du contrôle de signature et un patch de Gatekeeper, ce qui supprime la limitation des essais (Osservatorio Nessuno, mai 2026).

Oxygen démontrait dès 2022 une extraction sur un Redmi 10 (MediaTek Helio G88, Android 11) verrouillé : « We do it the opposite way and pull all the data first », puis la clé matérielle est lue séparément et combinée pour attaquer le chiffrement par dictionnaire (mot de passe retrouvé après environ 40 000 essais) (Forensic Focus / Oxygen, 2022). MSAB (XRY) revendique le support bootrom de dix puces MediaTek (MT6739 à MT6893) et le déchiffrement de « many of the available TEEs » (MSAB, MediaTek). Les puces Unisoc/Spreadtrum ont un mode de téléchargement exploitable qui « can't be patched by software update » (Belkasoft). Conclusion d'Osservatorio Nessuno : un appareil MediaTek n'a « practically no mitigation possible, except ditching it » (Osservatorio Nessuno, mars 2025).

Samsung : couverture large, mais sources surtout vendeurs

Samsung dispose depuis le Galaxy S21 d'un élément sécurisé distinct, Knox Vault. Samsung le décrit comme un sous-système isolé doté de son propre processeur et de sa propre mémoire, qui conserve le code de verrouillage et les données biométriques, impose des pauses croissantes entre les tentatives et s'efface lui-même s'il détecte une attaque physique (Samsung, Knox Vault). Sur le papier, le Galaxy S25 et le Galaxy S26 appartiennent donc à la même catégorie que les Pixel 6 et suivants et que les iPhone 12 et suivants : celle des appareils dont la limitation des essais ne s'attaque pas depuis le processeur principal.

Les Samsung récents restent couverts par au moins un vendeur. MSAB annonçait en 2021 une « rapid brute force solution » en BFU avec extraction FFS sur Galaxy S20 et Note 20 Qualcomm, puis en novembre 2024 (XRY 10.11.1) une force brute et une extraction pour les Galaxy S24, S24+, S24 Ultra, Z Flip6 et Z Fold6, ainsi qu'une force brute BFU sur des Exynos de série A (MSAB, Qualcomm ; Forensic Focus, XRY 10.11.1).

Un fait vérifié et non commercial vient de Serbie : Amnesty International a documenté le déverrouillage par Cellebrite d'un Galaxy S24+ (octobre 2024) et surtout d'un Galaxy A32 saisi éteint le 25 décembre 2024, ouvert en environ quatre minutes entre la connexion d'un périphérique USB émulé et l'obtention des droits « root » (Amnesty Security Lab, fév. 2025). Le A32 est un milieu de gamme sans élément sécurisé indépendant : le patch de Gatekeeper est l'hypothèse la plus cohérente, mais le rapport ne précise pas si un vrai brute force du code a été nécessaire. Le statut des Samsung haut de gamme face au brute force repose surtout sur des affirmations de vendeurs ; le statut du Galaxy S25 n'est documenté par aucune source primaire.

Deux faits récents modifient le tableau pour les deux derniers modèles. D'abord, Samsung a déployé une fonction de redémarrage d'inactivité, l'Inactivity Restart, qui ramène l'appareil en état BFU après septante-deux heures sans déverrouillage. Elle est arrivée sur les Galaxy S25 fin 2025, puis sur les Galaxy S26 au début de 2026 (SamMobile, mars 2026). Elle reste optionnelle et se trouve dans les réglages de sécurité. Un S25 ou un S26 sur lequel elle est activée se comporte donc comme un iPhone sous iOS 18.1 : saisi un vendredi et branché le lundi suivant, il peut déjà être revenu dans son état le plus fermé.

Ensuite, un Galaxy S26 a été compromis en octobre 2026 lors du concours Pwn2Own Ireland, par une chaîne de failles déclenchée par un simple courriel (Cybernews, octobre 2026). Ce fait doit être lu pour ce qu'il est. Il s'agit d'une attaque à distance contre un appareil en fonctionnement, sans accès physique, et elle ne dit rien de la résistance d'un appareil verrouillé ni de la force brute du code. Elle rappelle seulement qu'un téléphone récent n'est pas inviolable, et que des failles exploitables subsistent toujours quelque part dans la chaîne.

Pixel et la puce Titan M2 : la résistance la mieux documentée côté Android

Les Google Pixel 6 et suivants embarquent l'élément sécurisé Titan M2. GrapheneOS, qui suit de près les documents Cellebrite, affirme que les sociétés forensiques contournent la limitation sur les Pixel 2 à 5 et sur des implémentations Samsung et Qualcomm, mais que sur Titan M2 « it appears they didn't have a working exploit for it at any point » ; en conséquence, « Pixel 6 and later, and the latest iPhones, are the only devices where a random 6-digit PIN can't practically be brute-forced » (GrapheneOS forum).

La fuite d'octobre 2025, issue d'un appel Teams de Cellebrite, confirme que sur Pixel d'origine Cellebrite peut extraire certaines données en BFU et davantage en AFU, mais « cannot brute-force passcodes to gain full control of the device », et que les eSIM Pixel ne sont pas copiables (HackMag ; Android Authority, 30 oct. 2025). Google a par ailleurs corrigé en avril et juin 2024 des failles du firmware Pixel (CVE-2024-29745, CVE-2024-29748, CVE-2024-32896) que, selon GrapheneOS, des sociétés forensiques exploitaient pour lire la mémoire d'appareils en AFU via le mode fastboot et contourner l'effacement de contrainte (BleepingComputer, avril 2024).

GrapheneOS : le cas le plus résistant

GrapheneOS, système Android durci pour Pixel, apparaît dans les matrices Cellebrite comme non exploitable dès lors que les correctifs sont postérieurs à la fin 2022 ; la fuite d'octobre 2025 indique que depuis fin 2024, même un GrapheneOS déverrouillé ne se laisse plus extraire en full file system (HackMag ; Android Authority). Le blog 9x0rg relève que « Google Pixel devices with GrapheneOS are the only devices explicitly mentioned by Cellebrite as unaffected by their exploits » (9x0rg, avril 2025). GrapheneOS ajoute par défaut un redémarrage automatique après 18 heures de verrouillage, un port USB-C en « charge seule quand verrouillé », et un code de contrainte qui efface l'appareil (GrapheneOS features).

Android 16 et le mode Advanced Protection

Android 16 a introduit en mai 2025 un mode « Advanced Protection » (protection avancée), optionnel et désactivé par défaut, qui ajoute un redémarrage automatique après 72 heures de verrouillage et une protection USB coupant les nouvelles connexions quand l'appareil est verrouillé (Android Authority, Advanced Protection). Google a aussi déployé, via Google Play services (avril 2025), un redémarrage automatique des téléphones « locked for 3 consecutive days », livré sans mise à jour du système (9to5Google, 16 avril 2025). Comme ces fonctions ne sont pas actives par défaut, un Android ordinaire saisi en AFU le reste tant qu'il est alimenté, ce qui explique l'intérêt des modes « préservation » des vendeurs.

Attaques de bas niveau et chaînes USB

Au-delà des puces bon marché, deux voies physiques existent. Le mode EDL (Emergency Download) de Qualcomm permet, sur d'anciens SoC, de lire la flash ; Cellebrite vend une capacité dédiée (Cellebrite, EDL). Surtout, le cas serbe du Galaxy A32 a révélé une chaîne de failles du noyau Linux déclenchées par un faux périphérique USB : CVE-2024-53104 (pilote vidéo UVC), CVE-2024-53197 (audio USB) et CVE-2024-50302 (HID), permettant d'obtenir les droits root sur un appareil verrouillé dont le noyau n'était pas à jour (Amnesty Security Lab, fév. 2025). Ces failles ne dépendaient pas du fabricant : c'est l'argument central des protections « USB charge seule quand verrouillé ».

Tableau de synthèse Android (état au 18 octobre 2026)

Appareil / puce	Versions Android	Saisi éteint ou redémarré (BFU), code inconnu	Saisi allumé et déverrouillé (AFU)	Qualification de la source
Samsung Galaxy S3-S5, Note 3-4	Android 5.x	Extraction physique « bootloader method », verrouillage contourné (2015)	Idem	Vendeur (Cellebrite)
Samsung Exynos S9, séries A et J	jusqu’à Android 9	« Decrypting bootloader » (2019) ; dictionnaire via ODIN (Oxygen, 2021)	Idem	Vendeur
Samsung Qualcomm S20 et Note 20	non précisé	« Rapid brute force » BFU et FFS (MSAB, 2021)	Idem	Vendeur
Samsung S24, S24+, S24 Ultra, Z Flip6, Z Fold6	Android 14 à la sortie	Force brute et extraction « XRY Pro » (MSAB, nov. 2024)	S24+ déverrouillé par Cellebrite en Serbie (oct. 2024)	Vendeur ; fait documenté par Amnesty
Samsung Galaxy A32	non précisé	Déverrouillé éteint en environ 4 min via chaîne USB noyau (Cellebrite, déc. 2024)	—	Fait vérifié (Amnesty)
Samsung Galaxy S25 et S26	Android 15/16	Aucune source primaire	Aucune source primaire	Lacune documentaire
Google Pixel 2-5 et 5a (Titan M / NXP)	jusqu’à Android 13/14	Limitation de l’élément sécurisé contournée selon GrapheneOS ; force brute possible	FFS	Fuite / GrapheneOS
Google Pixel 6-9 d’origine (Titan M2)	Android 12-16	Pas de force brute ; données DE (BFU) limitées ; eSIM non extractible	FFS via exploits, avec quelques mois de retard après chaque nouvelle version	Fuites rapportées (avril 2024, fév. 2025, oct. 2025)
Pixel sous GrapheneOS, correctifs postérieurs à fin 2022	—	Non exploitable	Non exploitable ; depuis fin 2024, pas de FFS même déverrouillé	Fuite rapportée
Qualcomm génériques (Xiaomi, OnePlus, Oppo, Vivo, Motorola)	Android 7-14	Exploitable « dans la grande majorité des cas » ; EDL sur anciens SoC	Exploitable	Fuite et vendeurs
MediaTek (MT65xx/67xx/68xx, Helio, certains Dimensity)	Android 7-13 documentés	Bootrom incorrigible : extraction, clés FBE et force brute hors ligne ; « unmitigable »	Idem	Vendeur et analyse secondaire
Unisoc/Spreadtrum, Kirin 970 et 980	non précisé	Mode téléchargement ou point de test ; clés FBE extractibles sur certains modèles	Idem	Vendeur (Belkasoft, MSAB)
Tout Android, noyau non corrigé avant fév. 2025, USB actif	toutes	Chaîne CVE-2024-53104, 53197 et 50302 : droits root via USB émulé	Idem	Fait vérifié (Amnesty)
Android 16 avec Advanced Protection activé	Android 16	Redémarrage après 72 h ; USB en charge seule quand verrouillé	Fenêtre AFU limitée à 72 h	Annonce Google ; efficacité face aux outils non documentée

Les quatre facteurs qui décident en pratique

Quatre variables commandent le résultat, dans l'ordre d'importance.

La longueur et le type du code

C'est la protection la plus efficace entre les mains de l'utilisateur. Les estimations publiques de référence (Matthew Green, 2018, sous l'hypothèse d'un exploit neutralisant la Secure Enclave) donnent, pour un code décimal aléatoire : 4 chiffres, 13 minutes au pire et 6,5 minutes en moyenne ; 6 chiffres, 22 heures au pire et 11 heures en moyenne ; 8 chiffres, 92 jours au pire et 46 jours en moyenne ; 10 chiffres, plus de neuf mille jours (Privacy Guides, Cellebrite bruteforce rate). Ces chiffres supposent un exploit, qui n'existe pas pour toutes les générations.

En 2023, Elcomsoft indiquait que le mode le plus rapide de Cellebrite, « Supersonic », plafonnait à « slightly above 5,000 APD » (essais par jour), soit environ 200 jours pour épuiser l'espace des codes à 6 chiffres (Elcomsoft, 2023). Les outils commencent toujours par des listes de codes fréquents et de dates de naissance, ce qui explique les succès rapides sur des codes faibles et les échecs sur des codes aléatoires.

Côté Android, lorsque la limitation est contournée, Osservatorio Nessuno estime un code de 6 chiffres ou moins « trivially recoverable » et même un code de 10 chiffres récupérable « in seconds » ; mais sur élément sécurisé non contourné (Titan M2), un code aléatoire à 6 chiffres n'est pas praticable et un mot de passe alphanumérique est « likely unbreakable » (Osservatorio Nessuno, mai 2026). GrapheneOS recommande une phrase de passe de 6 à 8 mots. Un schéma de déverrouillage vaut au mieux un code court.

L'état AFU ou BFU et le délai avant branchement

Un téléphone saisi allumé et déverrouillé depuis le démarrage livre la plupart de ses données ; éteint ou redémarré, il ne livre qu'une fraction. Depuis iOS 18.1 et Android 16 (en option), l'état AFU est perdu après 72 heures sans déverrouillage, 18 heures sur GrapheneOS. La date de saisie, la date de branchement à l'outil et l'intervalle entre les deux deviennent donc des faits décisifs (Jiska Classen, 2024).

Le couple modèle et version d'OS face aux exploits disponibles

Les matrices fuitées montrent des « trous » de plusieurs mois après chaque nouvelle version : un téléphone très à jour au moment de la saisie peut être temporairement non exploitable, puis le devenir quand l'exploit sort. Le cas Pensacola (iPhone ouvert plus de quatre mois après les faits) et le trou iOS 17.4 d'avril 2024 illustrent ce délai (NPR, 2020). La version de l'outil elle-même compte : Cellebrite Premium 7.69.5 (juillet 2024) et 7.73.1 (février 2025) n'ont pas les mêmes capacités.

La biométrie et l'ordinateur appairé

La reconnaissance du doigt ou du visage n'ouvre une fenêtre que brièvement : Apple réexige le code après un redémarrage, après 48 heures sans déverrouillage, après 156 heures sans saisie du code, après cinq échecs biométriques, ou si le geste SOS est déclenché (Apple, Face ID, Touch ID, passcodes). Un suspect averti neutralise cette voie en quelques secondes. Un ordinateur appairé saisi avec le téléphone peut valoir plus que le téléphone : un enregistrement d'appairage valide, plus un appareil en AFU, permet une sauvegarde complète sans code, mais seulement si l'appareil n'a pas redémarré (Elcomsoft, lockdown records).

En somme, les durées réalistes vont de quelques minutes (Samsung milieu de gamme avec exploit frais, ou code à 4 chiffres sur appareil exploitable) à l'impossibilité pratique (iPhone récent éteint avec mot de passe long). La variance observée dans les affaires publiques, 40 minutes pour le Samsung de Butler en juillet 2024 et plus de quatre mois pour l'iPhone de Pensacola, tient moins à la puissance de l'outil qu'au calendrier des exploits (Techdirt, 2024).

Qui fait quoi en Belgique, et avec quels outils

Trois niveaux

L'extraction mobile belge s'organise à trois niveaux. Les zones de police locale disposent de licences Cellebrite UFED, souvent via le contrat interzonal piloté par Anvers. Les 14 RCCU (police judiciaire fédérale déconcentrée) et la FCCU (unité centrale à Bruxelles, au sein de DJSOC) disposent d'un laboratoire « Mobile Forensics » qui « craque les codes d'accès par ses propres méthodes », y compris JTAG et chip-off, avec les outils UFED, Oxygen et Axiom Mobile (Jobpol, présentation 2024). La NTSU (unité d'appui technique de la police judiciaire fédérale) gère les opérations techniques secrètes et a joué un rôle « crucial » dans le craquage de Sky ECC (VRT NWS, 25 mars 2021).

Le point de contact 24 heures sur 24 pour la preuve électronique est la FCCU (EJN, fiches belges). Les zones le disent sans détour : « les appareils verrouillés doivent passer par la police fédérale, qui a de longs délais d'attente » (PV Demerdal-DSZ, 18 juin 2024). La police fédérale reconnaît un « déficit criant de personnel » dans les RCCU, avec un besoin d'au moins vingt personnes supplémentaires (police.be, déc. 2023).

Les outils et leurs prix, relevés dans les conseils de police

Cellebrite UFED (versions 4PC, Premium, Cloud) est l'outil dominant. Au moins 39 zones de police flamandes l'utilisent, dont au moins 15 via le contrat interzonal d'Anvers, qui facture 4 % de frais administratifs (VRT NWS, 8 août 2025).

Les procès-verbaux des conseils de police donnent des ordres de grandeur précis : la zone Demerdal-DSZ avait une licence de base à 7 200 euros par an et a rejoint le « Cellebrite Unity Project » pour environ 15 000 euros par an (60 000 euros sur quatre ans) avec « déverrouillages illimités » (PV Demerdal-DSZ, 2024) ; la zone Lanaken-Maasmechelen a acheté UFED 4PC avec extensions Premium et Cloud pour un investissement unique d'environ 21 000 euros et une licence annuelle de 19 000 euros, abandonnant son ancienne licence XRY (MSAB) devenue insuffisante « pour la nouvelle technologie mobile » (PV Lanaken-Maasmechelen, mars 2024). Le passage de XRY à Cellebrite en 2024 indique que l'outil standard ne suffisait plus pour les appareils récents.

À titre de comparaison, les marchés publics américains situent Cellebrite Premium autour de 20 000 dollars par an et GrayKey entre 33 000 et 54 000 dollars par an (Civic IQ), et la police londonienne a publié un marché d'extension Premium de 5,4 millions de livres hors taxes en 2025 (Find a Tender).

GrayKey à la Douane

L'Administration générale des douanes et accises (SPF Finances) utilise GrayKey depuis janvier 2024, acheté via une société néerlandaise pour un peu plus de 64 000 euros (licence de quatre ans) ; 17 téléphones ont été déverrouillés en deux ans, uniquement en fraude grave et avec l'autorisation d'un magistrat (VRT NWS, 5 mars 2026). L'expert Inti De Ceukelaire estime que l'outil fonctionne mieux sur les anciens téléphones, ce qui recoupe l'ensemble des constats techniques ci-dessus.

Le service en laboratoire et la coopération internationale

Quand l'outil sur site échoue, le circuit réel est l'envoi au laboratoire du fournisseur, Cellebrite Advanced Services (CAS), qui dispose de « 10 secure labs around the world » et revendique un accès AFU aux iPhone verrouillés et un « 100% success rate » (affirmations de vendeur, sans prix public ; un coût de 4 000 dollars par appareil a été rapporté en 2022) (Cellebrite CAS ; 9to5Mac, 2022).

Au niveau européen, une plateforme de déchiffrement Europol et JRC existe depuis fin 2020, mais elle sert à casser des mots de passe de fichiers et de conteneurs, pas à exploiter des failles iOS ou Android, et aucune utilisation belge pour un smartphone n'est documentée (eucrim). Le seul recours étranger belge documenté est l'appui du FBI en mars 2016 pour les attentats de Bruxelles (Fox News, 2016). Aux Pays-Bas, le NFI a ouvert des cryptophones dans le cadre d'un projet européen de trois ans (NOS, 2023).

Sky ECC, le contre-exemple « côté serveur »

Le grand succès belge n'est pas un déverrouillage d'appareil mais une interception réseau. Sky ECC a été compromis par un dispositif « man-in-the-middle » sur les serveurs OVH de Roubaix : environ un milliard de messages interceptés, dont près de la moitié déchiffrés, et plus de 1 200 condamnations en Belgique au 28 février 2026, pour 3 684 années de prison cumulées (Eurojust ; Hespress, 28 fév. 2026). Ce modèle montre, en creux, que l'extraction d'un iPhone récent verrouillé reste une difficulté opérationnelle ; la ligne de défense actuelle dans les dossiers Sky ECC porte d'ailleurs sur la chaîne de garde des données, pas sur le déverrouillage (Computer Weekly, 2 fév. 2026).

Les voies alternatives quand le téléphone résiste

Le cloud Apple

Sans l'option « Advanced Data Protection » (ADP), Apple détient les clés de la sauvegarde iCloud et peut la remettre sur demande légale valable ; comme la sauvegarde contient la clé de « Messages in iCloud », Apple peut aussi accéder aux iMessages lorsque la sauvegarde est activée (Zinkus et al., 2021 ; Apple, Law Enforcement Guidelines). Mais pour un iPhone verrouillé lui-même, Apple est claire : depuis iOS 8, elle « cannot perform a data extraction » et ne peut fournir le code.

Les chiffres belges du rapport de transparence d'Apple sont parlants : au second semestre 2024, pour les 101 demandes de compte visant la Belgique (149 comptes), Apple a fourni des données non-contenu dans 67 % des cas mais zéro contenu (photos, courriels, sauvegardes), le contenu n'étant remis quasi exclusivement qu'aux États-Unis et exigeant pour la Belgique la voie MLAT ou CLOUD Act (Apple Transparency 2024 H2).

Lorsque l'utilisateur a activé l'ADP (optionnelle depuis iOS 16.2, décembre 2022), 25 catégories dont la sauvegarde, Photos et Notes deviennent chiffrées de bout en bout et inaccessibles à Apple comme aux outils cloud (Apple, Advanced Data Protection). La saga britannique montre l'enjeu : le Royaume-Uni a imposé en 2025 une injonction technique (Technical Capability Notice), Apple a retiré l'ADP au Royaume-Uni en février 2025, et la bataille judiciaire se poursuit (iClarified, août 2026).

Le compte Google et les messageries

Les sauvegardes d'applications Android (depuis Android 9) sont chiffrées côté client avec une clé protégée par le code de verrouillage et une puce Titan dans les centres de données de Google, de sorte que « no one, including Google » ne peut y accéder sans le code (Google Security Blog, 2018). En revanche, la plupart des autres données du compte Google (Gmail, Photos, Drive, historique de localisation) restent accessibles à Google et donc remises sur réquisition (Johns Hopkins, 2021). Les sauvegardes WhatsApp ne sont chiffrées de bout en bout que si l'utilisateur a activé l'option, disponible depuis octobre 2021 (Meta, 2021).

e-Evidence, opérateurs, appareils appairés, chip-off

Depuis le 18 août 2026, le règlement européen e-Evidence (UE 2023/1543) permet des injonctions directes de conservation (60 jours) et de production adressées aux fournisseurs de messagerie et de télécommunications ayant un établissement ou un représentant dans l'Union, avec un délai de réponse de 10 jours (8 heures en urgence) et une notification à l'État d'exécution pour le trafic et le contenu (BfDI, e-Evidence). Ce texte change le canal et le délai, mais ne crée aucun accès au contenu chiffré de bout en bout.

Un ordinateur appairé peut livrer une sauvegarde complète sans code si le téléphone est en AFU (Elcomsoft, lockdown records). Enfin, le chip-off et le JTAG restent utiles pour les appareils très anciens ou pour obtenir une image chiffrée à déchiffrer ensuite, mais le NFI néerlandais précise que les cryptophones actuels imposent de modifier les puces avant d'utiliser un logiciel avancé (NOS, 2023).

Une donnée connexe, souvent oubliée : l'exploitation d'un téléphone alimente ensuite des banques de données policières. Nous l'expliquons dans notre article sur la BNG, la banque de données nationale générale.

Le cadre juridique belge, en bref

Cette section est volontairement brève : elle sert à situer la technique, non à traiter le droit. Nos articles juridiques le font en détail.

Le refus de communiquer le code d'accès est punissable en Belgique, et la solution est consolidée. L'article 88quater du Code d'instruction criminelle distingue une obligation d'information, au paragraphe 1er, à laquelle le suspect n'est pas soustrait, et une obligation de coopération active, au paragraphe 2, dont l'inculpé est expressément exclu (Cour constitutionnelle, n° 28/2020). Par son arrêt du 4 février 2020 (P.19.1086.N), la Cour de cassation a jugé le refus punissable, au motif que « le code d'accès à un système informatique existe indépendamment de la volonté de la personne qui a connaissance de ce code ». Elle pose deux conditions : l'autorité doit avoir déjà examiné l'appareil « sans recours à la contrainte sur la personne », et doit démontrer « au-delà de tout doute raisonnable » que la personne connaît le code (UCLouvain, arrêt et note Forget).

Depuis le 1er septembre 2026, la peine ne figure plus au Code d'instruction criminelle mais aux articles 655 et 656 du nouveau Code pénal, par une loi de mise en concordance « à droit constant » : peine de niveau 2 pour le refus simple, de niveau 3 pour la forme aggravée, avec une amende accessoire pouvant atteindre 160 000 euros et, dans la forme aggravée, 400 000 euros (DOC 56 1256/009). Ce que recouvrent ces niveaux est détaillé dans notre article sur les niveaux de peine. La Cour européenne des droits de l'homme a par ailleurs validé le modèle français voisin dans Minteh c. France, le 19 mai 2026 (Verfassungsblog).

Pour la fouille du contenu, l'arrêt de la Cour de justice de l'Union Landeck (4 octobre 2024) impose en principe une autorisation préalable d'un juge ou d'une autorité indépendante, y compris pour les tentatives de déverrouillage (CJUE, communiqué 171/24). Aucune disposition belge spécifique ne régit le déverrouillage biométrique forcé ; la jurisprudence néerlandaise (Hoge Raad, 9 février 2021) admet l'apposition forcée du doigt « sans violence » lorsque aucun moyen technique n'existe, en distinguant l'empreinte, indépendante de la volonté, du code, qui est une déclaration (bijzonderstrafrecht.nl).

Sur ces questions, voyez nos articles dédiés : la police peut-elle exiger le code de votre téléphone, comment récupérer un téléphone saisi, ce que la police peut exiger du téléphone d'un mineur et ce que devient un appareil gardé après l'audition.

Les questions à poser sur le procès-verbal d'extraction

La technique précède ici la défense. Dans un dossier où un téléphone a été exploité, ou n'a pas pu l'être, les faits vérifiables suivants devraient figurer au procès-verbal d'extraction, ou être demandés.

Sur l'état de l'appareil à la saisie. Le téléphone était-il allumé ou éteint, verrouillé ou déverrouillé (état AFU ou BFU) ? A-t-il été mis en mode avion, placé en sac de Faraday, maintenu sous alimentation ? Ces points conditionnent ce qui était techniquement accessible et relèvent des bonnes pratiques (NIST, SWGDE).

Sur la chronologie. Quelles sont la date et l'heure exactes de la saisie, et celles du premier branchement à l'outil d'extraction ? L'intervalle dépasse-t-il 72 heures (iOS 18.1 et suivants, Android 16) ou 18 heures (GrapheneOS) ? Le fichier shutdown.log ou le message « Face ID requires your passcode when iPhone restarts » attestent-ils d'un redémarrage d'inactivité survenu sous scellé ?

Sur l'appareil et le système. Quels sont le modèle exact (référence commerciale et, pour Android, la puce : Qualcomm, Exynos, Tensor, MediaTek, Unisoc) et la version précise du système au moment de la saisie ? Ces données déterminent si un exploit existait à cette date.

Sur l'outil. Quel outil et quelle version ont été utilisés (Cellebrite UFED, Premium, Inseyets 10.x, 7.69.5, 7.73.1 ; GrayKey ; XRY) ? L'extraction a-t-elle été faite localement ou par le service en laboratoire du fournisseur, ce qui implique un transfert de l'appareil et des maillons supplémentaires dans la chaîne de garde ?

Sur le mode d'extraction. S'agit-il d'une extraction logique, full file system, ou physique ? Le code a-t-il été réellement retrouvé par force brute, et dans ce cas lequel, de quelle longueur et de quel type, ou les données ont-elles été lues en état AFU sans jamais casser le code ? Cette distinction compte : si l'appareil était en réalité exploitable en AFU, l'argument de nécessité qui fonde l'obligation de livrer le code s'en trouve fragilisé.

Sur le fondement juridique. La recherche a-t-elle été autorisée par une autorité indépendante au sens de l'arrêt Landeck, y compris pour les tentatives de déverrouillage ? S'il y a eu contrainte physique (apposition du doigt, du visage), sur quelle base légale précise, compte tenu de l'absence de texte belge spécifique ?

Une obligation matérielle est venue s'ajouter à ces vérifications. L'article 39bis du Code d'instruction criminelle a été refondu par la loi du 8 février 2026, en vigueur le 26 février 2026, en réponse à la jurisprudence européenne. Les recherches « peuvent uniquement s'étendre aux données sauvegardées dans le système informatique qui est saisi », et « toute connexion externe de ce système informatique est empêchée avant que la recherche soit entamée ». Le procès-verbal doit donc établir que l'appareil a été coupé du réseau avant le début de l'examen. Le même texte exige, à défaut d'un consentement écrit précédé de l'information que les données trouvées pourront servir de preuve, l'autorisation préalable du juge d'instruction, ainsi qu'une motivation reflétant le caractère proportionnel de la mesure par rapport à la vie privée.

Deux faits de contexte sont utiles : aucune autorité européenne ne publie de taux de réussite de déverrouillage, et le seul chiffre officiel jamais avancé, celui du FBI annonçant 6 900 appareils inaccessibles en 2017, a dû être retiré après un aveu d'erreur de comptage ramenant le total à 1 000 ou 2 000 (NPR, 2018). Si une audition est prévue dans un tel dossier, voyez comment la préparer avec un avocat.

Questions fréquentes

La police peut-elle récupérer des SMS ou des messages effacés ?

La question se pose en deux temps, et le premier commande le second. Tant que l'appareil n'est pas ouvert, elle ne se pose pas : un téléphone éteint, récent et protégé par un code long ne livre rien, effacé ou non. Si l'appareil est exploitable, ce qui est récupéré dépend du niveau d'extraction obtenu. Une extraction logique ne donne que ce que le téléphone accepte de livrer ; une extraction full file system donne accès aux bases de données des applications, où des éléments supprimés peuvent subsister tant qu'ils n'ont pas été écrasés. C'est pourquoi le procès-verbal doit préciser le mode d'extraction employé.

La police peut-elle lire mes messages WhatsApp ?

Sur l'appareil lui-même, si l'extraction réussit, les conversations présentes sur le téléphone sont lisibles comme le reste. Par la voie du cloud, cela dépend d'un réglage : les sauvegardes WhatsApp ne sont chiffrées de bout en bout que si l'utilisateur a activé l'option, disponible depuis octobre 2021. Sans cette option, la sauvegarde est accessible au fournisseur de l'espace de stockage et peut être réclamée par voie légale. Le chiffrement de bout en bout des conversations elles-mêmes, lui, ne protège pas le contenu une fois le téléphone ouvert : il protège le transport, pas l'appareil. Pour le cas particulier de Snapchat, dont les messages s'effacent par défaut, voyez notre article dédié.

Nous détaillons cette question, base de données par base de données, dans notre article consacré à WhatsApp.

Les autres messageries font l’objet d’articles distincts, car elles ne se comportent pas de la même façon : Messenger, la messagerie d’Instagram, Telegram et Snapchat.

Et pour les appels, y compris les appels chiffrés et les chiffres réels des écoutes en Belgique, voyez notre article sur l’interception des appels.

Combien de temps la police peut-elle garder mon téléphone ?

C'est une question juridique distincte de la question technique traitée ici, et elle a sa propre réponse. Nous l'expliquons en détail dans notre article sur la récupération d'un téléphone saisi. Retenez tout de même un point technique : plus l'appareil reste longtemps sous scellé sans être branché, plus il est probable qu'il ait basculé dans l'état le plus résistant, par l'effet du redémarrage automatique.

La police peut-elle déverrouiller n'importe quel téléphone ?

Non. Trois variables décident : l'état de l'appareil à la saisie (allumé et déjà déverrouillé, ou éteint), son âge et sa puce, et la longueur du code. Un téléphone bon marché à puce MediaTek saisi allumé livre pratiquement tout ; un iPhone récent éteint, protégé par une phrase de passe, n'est ouvert par aucun outil public à ce jour.

Qu'est-ce que l'état AFU et l'état BFU ?

AFU (After First Unlock) désigne un téléphone déverrouillé au moins une fois depuis son démarrage : les clés de chiffrement sont en mémoire vive et les outils extraient la majorité des données sans connaître le code. BFU (Before First Unlock) désigne un appareil éteint ou redémarré sans saisie du code : les clés n'ont jamais été calculées, et seule une fraction des données est lisible.

Un iPhone est-il plus sûr qu'un Android ?

La question est mal posée. La ligne de partage ne sépare pas les deux systèmes mais les générations et les puces. Un iPhone de 2016 est plus exposé qu'un Pixel 8 ; un Android bon marché à puce MediaTek est plus exposé qu'un iPhone 15. Ce qui compte est l'existence d'un élément sécurisé non contourné et la longueur du code.

Que change le redémarrage automatique après 72 heures ?

Depuis iOS 18.1, un iPhone resté verrouillé trois jours redémarre seul et repasse en état BFU, le plus résistant. Android 16 propose la même chose en option. La conséquence pratique est que la date de saisie et la date de branchement à l'outil deviennent des faits décisifs du dossier : un appareil saisi un vendredi et branché le lundi peut avoir basculé.

Un code à six chiffres suffit-il ?

Il suffit tant qu'aucun exploit ne neutralise la limitation des essais. Si un exploit existe pour le modèle, un code à six chiffres tombe en heures ou en jours. Un mot de passe alphanumérique long reste hors de portée des outils documentés, quel que soit l'appareil.

Quels outils la police belge utilise-t-elle ?

Cellebrite UFED domine : au moins 39 zones de police flamandes l'utilisent, souvent via le contrat interzonal d'Anvers, avec des licences allant de 7 200 à 19 000 euros par an. La Douane dispose de GrayKey depuis janvier 2024. Les appareils que les zones n'ouvrent pas remontent vers la police fédérale, dont les délais sont reconnus comme longs.

La police peut-elle accéder à mes sauvegardes iCloud ?

Sans l'option Advanced Data Protection, Apple détient les clés de la sauvegarde et peut la remettre sur demande légale valable. Mais le rapport de transparence d'Apple montre qu'au second semestre 2024, pour les demandes visant la Belgique, aucun contenu n'a été fourni : le contenu suppose la voie MLAT ou le CLOUD Act. Avec l'option activée, la sauvegarde est chiffrée de bout en bout et inaccessible à Apple.

Que risque-t-on à refuser de donner son code en Belgique ?

Le refus est punissable depuis l'arrêt de la Cour de cassation du 4 février 2020, sous deux conditions : l'appareil doit avoir été trouvé et examiné sans contrainte sur la personne, et la connaissance du code doit être établie au-delà de tout doute raisonnable. Depuis le 1er septembre 2026, la peine relève des articles 655 et 656 du nouveau Code pénal. Nous traitons cette question en détail dans un article distinct.

Conclusion

La réponse à la question posée ne tient pas dans un oui ou un non, et surtout pas dans l'opposition entre Android et Apple que l'on entend souvent. En octobre 2026, un smartphone verrouillé est, pour les autorités belges, une cible dont la difficulté se mesure à trois curseurs.

L'état de saisie d'abord : le téléphone allumé et déjà déverrouillé est la règle d'or de l'enquêteur, l'appareil éteint depuis plus de 72 heures la meilleure défense de l'utilisateur. L'âge matériel ensuite : les failles incorrigibles des puces anciennes et des téléphones bon marché les condamnent à vie, tandis que les iPhone 12 et suivants et les Pixel 6 et suivants, éteints, résistent à la force brute d'après tout ce qui est public. La force du code enfin : un code à six chiffres aléatoire ou, mieux, une phrase de passe change l'issue plus sûrement que n'importe quel réglage.

La nouveauté marquante de 2024 à 2026 est le redémarrage d'inactivité, qui a transformé la saisie en course contre la montre et poussé les vendeurs vers des modes de « préservation » dont nul, hors d'eux-mêmes, n'a vérifié l'efficacité.

Olivier Dupont — avocat depuis 2007, pratiquant quotidiennement le droit pénal, le droit de la jeunesse, et le droit des personnes vulnérables, titulaire de l'agrément requis pour intervenir devant la Cour de cassation en matière pénale.

Cet article décrit l'état public des capacités techniques d'extraction au 18 octobre 2026. Il est destiné à être mis à jour : les capacités des outils évoluent à chaque version de système, et une affirmation exacte aujourd'hui peut cesser de l'être dans six mois. Il ne constitue pas un avis juridique sur une situation particulière.