Pourquoi votre SSD externe est devenu lent sur Mac : le problème Trim

Le SSD externe qui copiait un dossier de projet de 40 Go à 900 Mo/s au printemps dernier met désormais onze minutes pour faire le même travail. Rien d'autre n'a changé. Même câble, même port, même Mac, même disque. Et quand vous recopiez ce dossier depuis le disque, ça vole toujours. Les lectures sont exactement aussi rapides qu'elles l'ont toujours été. Seule l'écriture s'est effondrée.

Cette asymétrie, c'est toute l'histoire. Un problème de câble ralentit les lectures et les écritures ensemble. Un port défaillant ralentit les lectures et les écritures ensemble. La limitation thermique ralentit tout, puis les performances reviennent quand le boîtier refroidit. Un disque dont la vitesse d'écriture s'est effondrée alors que sa vitesse de lecture est intacte vous montre une défaillance précise et bien comprise : sa mémoire flash n'a plus de blocs pré-effacés, et rien ne lui indique quels blocs il a le droit d'effacer. C'est un problème de Trim.

Le plus frustrant, c'est ce qui se passe ensuite. Vous cherchez comment vérifier l'état du Trim sur un Mac, et vous tombez sur les deux mêmes conseils répétés sur des dizaines de sites, dont un que nous avons publié nous-mêmes. Lancez system_profiler SPSerialATADataType | grep TRIM pour vérifier. Lancez sudo trimforce enable pour corriger. Sur un Mac moderne, la première commande n'affiche strictement rien, et la seconde ne fait absolument rien pour un disque USB. Ni l'une ni l'autre n'est une faute de frappe, ni l'une ni l'autre n'est obsolète, et aucune des deux ne produira un message d'erreur vous signalant qu'elle ne s'applique pas. Elles échouent simplement en silence à être pertinentes.

Ce guide corrige cela. Il explique ce que fait réellement le Trim et pourquoi son absence pénalise spécifiquement les écritures, vous montre comment distinguer un problème de Trim des quatre choses qui y ressemblent, démontre exactement pourquoi les deux vérifications standard échouent (avec des commandes que vous pouvez exécuter vous-même pour les voir échouer), puis vous donne les deux vérifications qui fonctionnent vraiment sur un Mac Apple silicon. Tout ce qui est présenté ici comme testé a été relevé sur un Mac Apple silicon exécutant macOS 26.5.2, build 25F84.

Points clés à retenir

• L'asymétrie lecture/écriture est le diagnostic — Howard Oakley, de The Eclectic Light Company, y met un chiffre : « Si sa vitesse d'écriture est tombée à 20 % ou moins de sa vitesse de lecture, alors vous pouvez être certain qu'il y a un problème de Trim. »
• sudo trimforce enable n'est pas une solution pour les disques externes — sa propre page de manuel indique qu'il active le Trim « sur les disques tiers connectés à un contrôleur AHCI », c'est-à-dire l'interface SATA, il n'a donc aucun effet sur un disque USB ou NVMe.
• system_profiler SPSerialATADataType n'affiche rien sur Apple silicon — ce type de données n'existe pas sur ces machines, si bien que la vérification de Trim la plus recopiée d'internet renvoie un résultat vide que les gens interprètent comme la preuve de n'importe quoi.
• Les vérifications qui fonctionnent sont system_profiler SPNVMeDataType et le journal unifié au moment du montage — APFS émet son balayage de Trim lorsqu'un volume est monté, vous devez donc débrancher le disque, noter l'heure, le rebrancher et lire le journal immédiatement.
• Le seul remède est un effacement complet et un reformatage — il n'existe aucune commande accessible à l'utilisateur qui déclenche un Trim à la demande, et Apple ne publie aucune liste de compatibilité indiquant quels boîtiers transmettent le Trim avant l'achat.

Ce que fait réellement le Trim, et pourquoi seules les écritures en souffrent

Le problème du bloc d'effacement

La mémoire flash porte une asymétrie gravée dans le silicium. Vous pouvez lire n'importe quelle page librement. Vous pouvez écrire dans une page actuellement effacée. Mais vous ne pouvez pas écraser une page qui contient déjà des données. Pour la réutiliser, le disque doit d'abord l'effacer, et l'effacement ne se fait pas page par page. Il se fait à l'échelle d'une unité bien plus grande appelée bloc d'effacement, qui contient de nombreuses pages.

Howard Oakley décrit la conséquence sans détour : « Avant que le SSD puisse écrire dans un bloc de mémoire qui a été utilisé, il doit l'effacer, et son temps de cycle effacement-écriture est lamentablement lent. »

C'est tout le mécanisme. Quand un disque dispose d'une réserve saine de blocs déjà effacés, une écriture entrante est une simple opération de programmation qui s'exécute à la vitesse nominale du disque. Quand il n'en a plus, chaque écriture entrante se transforme en une chaîne de travaux : trouver un bloc contenant des pages périmées, relire les pages encore valides, réécrire ces pages valides ailleurs, effacer le bloc entier, puis enfin écrire vos nouvelles données. Cette chaîne s'appelle lecture-modification-écriture, et elle peut coûter un ordre de grandeur de plus qu'une écriture propre.

Pourquoi le disque ne peut pas s'en sortir seul

Voici la partie qui surprend. Quand vous supprimez un fichier, le disque ne le sait pas. Le système de fichiers met à jour ses propres métadonnées pour marquer ces blocs logiques comme libres, mais du point de vue du contrôleur du disque, chaque bloc logique qu'on lui a un jour demandé d'écrire contient toujours des données valides. Il n'a aucun moyen de distinguer un bloc contenant une vidéo que vous avez supprimée le mois dernier d'un bloc contenant votre fichier de projet actif. Il doit préserver les deux.

Le Trim est le message qui comble cet écart. Quand un système de fichiers libère de l'espace, il peut envoyer une commande Trim listant les adresses de blocs logiques qui ne contiennent plus rien d'intéressant pour le système d'exploitation. Le disque les marque comme invalides et son ramasse-miettes en arrière-plan est alors libre de les consolider et de les effacer, constituant la réserve de blocs pré-effacés qui maintient les écritures rapides.

Sans Trim, cette réserve se réduit vers zéro à mesure que le disque se remplit, puis y reste pour toujours. Le disque n'est pas cassé et la flash n'est pas usée. Il passe simplement le plus clair de son temps à effectuer des cycles d'effacement qu'il aurait pu faire en arrière-plan des heures plus tôt.

Pourquoi les lectures restent parfaitement rapides

Une lecture ne nécessite jamais d'effacement. Une lecture, c'est une consultation dans la couche de traduction flash suivie d'une opération de détection sur une page. Que le disque contienne cent gigaoctets de données réellement valides ou cent gigaoctets de données logiquement supprimées il y a six mois ne change strictement rien à la vitesse à laquelle il peut vous restituer une page demandée.

C'est pourquoi le symptôme est si caractéristique, et pourquoi il mérite qu'on s'y fie. Un disque avec un problème de Trim n'est pas malade. Toutes les autres mesures que vous pouvez faire dessus paraissent normales : l'état S.M.A.R.T. est correct, le volume se monte instantanément, S.O.S. de Disk Utility passe sans erreur, les lectures séquentielles atteignent les mêmes chiffres qu'au premier jour. Seul le chemin d'écriture est dégradé, parce que seul le chemin d'écriture dépend de la disponibilité de blocs effacés.

À quoi ressemble un disque jamais trimmé au fil du temps

La dégradation n'est ni linéaire ni immédiate, ce qui explique pourquoi les gens mettent des mois à la remarquer.

Un SSD neuf ou fraîchement effacé a tous ses blocs à l'état effacé, donc les écritures passent directement. Cela tient jusqu'à ce que le disque ait été écrit sur environ la totalité de sa capacité au moins une fois. Le total d'octets écrits compte davantage que le taux de remplissage affiché dans le Finder à l'instant présent : un disque de 2 To qui n'a jamais contenu plus de 400 Go à un moment donné peut malgré tout avoir vu chacun de ses blocs physiques sollicité, si vous y avez fait transiter 400 Go de rushes vingt fois.

Passé ce point, un disque qui reçoit le Trim récupère proprement après chaque suppression. Un disque qui n'en reçoit pas ne récupère jamais. Son contrôleur garde chaque bloc qu'il a un jour écrit marqué comme valide, sa marge de surprovisionnement (la petite réserve que le fabricant met de côté, typiquement un pourcentage à un chiffre) est la seule zone libre restante, et il s'échine à faire de la lecture-modification-écriture pour chaque écriture entrante.

Ainsi, le disque semble aller bien pendant six à dix-huit mois puis, en quelques semaines, devient pénible. Rien ne s'est passé pendant ces semaines. Vous avez franchi un seuil.

La signature du symptôme : distinguer un problème de Trim de quatre sosies

Les disques externes lents sur un Mac ont plusieurs causes, et trois d'entre elles sont bien plus fréquentes que le Trim durant la première année de vie d'un disque. Avant d'effacer quoi que ce soit, confirmez que vous avez affaire à la bonne défaillance.

Le symptôme est assez répandu pour que les forums d'assistance d'Apple hébergent des fils récurrents à son sujet, dont la discussion 254727504, « Why is my external SSD so slow at writing? », et la discussion 255040461, « Slow external SSD ». Si vous voulez voir comment d'autres personnes ont décrit le même problème avant de commencer vos tests, c'est un endroit raisonnable où regarder.

Le test du ratio

Copiez un gros fichier, d'au moins 8 Go, dans chaque sens, et chronométrez les deux. Pas un dossier de petits fichiers, ce qui mesure la surcharge du système de fichiers plutôt que le débit brut. Un seul gros fichier.

Puis comparez. Si les lectures et les écritures sont toutes deux lentes et à peu près au même niveau, le problème est sur la connexion, pas dans la flash. Si les lectures sont normales et que les écritures n'en représentent qu'une fraction, vous êtes en territoire Trim. Le seuil d'Oakley est celui qu'il faut retenir : à 20 % ou moins de la vitesse de lecture, soyez certain de votre diagnostic.

Tableau comparatif des symptômes

Ce que vous observez	Cause la plus probable	Comment le confirmer
Écritures lentes, lectures normales, tout allait bien l'an dernier	Le Trim n'atteint pas le disque	Test du ratio, puis la vérification du journal au montage ci-dessous
Lectures et écritures lentes toutes les deux, dans une proportion similaire	Câble, port, ou un lien négocié en dessous de sa vitesse nominale	Changez de câble, essayez un autre port, vérifiez la vitesse négociée dans Informations Système
Démarre vite, chute brutalement après 20 à 60 secondes, récupère si vous faites une pause	Épuisement du cache d'écriture SLC ou limitation thermique	Lancez un seul transfert de plus de 3 minutes et observez la courbe ; touchez le boîtier
Lent uniquement avec des dossiers de nombreux petits fichiers	Surcharge du système de fichiers et des métadonnées, indexation Spotlight, logiciel de sécurité	Refaites l'essai avec un seul gros fichier ; si c'est rapide, ce n'est pas le disque
Déconnexions aléatoires, « Disque non éjecté correctement », le disque disparaît en pleine copie	Alimentation du bus ou gestion de l'alimentation du boîtier	Corrigez d'abord les déconnexions ; toute mesure de vitesse est peu fiable tant que ce n'est pas fait
Le disque apparaît dans Disk Utility mais pas dans le Finder, ou apparaît en double	Bug de la couche de montage, pas un problème de performance	Ce n'est pas du tout un défaut de vitesse, et l'effacer n'y changera rien
Lent sur un Mac, rapide sur un autre, avec le même câble	Le port, le hub ou le dock de ce Mac	Testez le disque directement sur les deux machines, sans hub entre les deux
Il a toujours été aussi lent, depuis le premier jour	Ce n'est pas le Trim. Vérifiez que c'est bien un SSD, et ce que le lien négocie	Un disque neuf a tous ses blocs effacés et ne peut pas encore avoir un problème de Trim

Cette dernière ligne mérite d'être soulignée, car elle évite à bien des gens d'effacer un disque pour rien. Un problème de Trim ne peut pas exister sur un disque qui a toujours été lent. La dégradation par manque de Trim exige un historique. Si le disque était lent dès la sortie de la boîte, regardez du côté du boîtier, du câble, et de savoir si le lien s'est établi à la vitesse que vous avez payée.

Écarter d'abord la connexion

Deux minutes de travail ici évitent un effacement inutile.

Ouvrez Informations Système (maintenez Option et cliquez sur le menu Pomme, puis Informations Système), et cherchez le disque sous USB ou Thunderbolt/USB4. Vérifiez la vitesse réellement négociée par le lien, pas celle imprimée sur la boîte. Un disque capable de 10 Gb/s qui s'est connecté sur un lien à 480 Mb/s à cause d'un câble de charge sera catastrophiquement lent dans les deux sens.

system_profiler SPUSBHostDataType

Cette commande affiche la même arborescence USB sous forme de texte, y compris la vitesse de lien de chaque périphérique connecté. Si vous êtes en Thunderbolt, utilisez plutôt SPThunderboltDataType. Ces deux types de données existent sur Apple silicon, ce qui, comme l'explique la section suivante, est plus qu'on ne peut dire de celui que tout le monde vous recommande d'utiliser.

Changez aussi de câble avant de conclure quoi que ce soit. Les câbles USB-C varient énormément dans ce qu'ils prennent réellement en charge, et un câble qui charge parfaitement peut être limité aux débits de données USB 2.0. Éliminer cette variable ne coûte rien et explique bien des signalements du type « mon SSD est devenu lent ».

Pourquoi les deux vérifications standard d'internet échouent sur un Mac moderne

C'est la section la plus importante, car les mauvais conseils ne sont pas seulement inutiles ici. Ils induisent activement en erreur, en produisant un résultat silencieux, vide et sans erreur que les gens interprètent comme une réponse.

trimforce ne fait pas ce que presque tout le monde prétend

Lancez man trimforce sur votre propre Mac. La page de manuel est toujours présente sur macOS 26.5.2 sur Apple silicon, ce qui explique en partie pourquoi ce conseil refuse de mourir. Voici ce qu'elle dit, mot pour mot.

La ligne NAME indique : « trimforce – enable TRIM commands on third-party drives. »

La DESCRIPTION indique : « trimforce enables sending TRIM commands to third-party drives attached to an AHCI controller. By default, TRIM commands are not sent to third-party drives. Use extreme caution when enabling TRIM, as some drives may not correctly handle the commands. trimforce must be run by the system administrator. »

Le verbe enable est documenté ainsi : « Start sending TRIM commands to AHCI-attached third-party drives. Requires a reboot to take effect. »

Et la section HISTORY indique : « The trimforce utility first appeared in OS X 10.10.4. »

Relisez la DESCRIPTION et arrêtez-vous sur quatre mots : attached to an AHCI controller. AHCI, l'Advanced Host Controller Interface, est l'interface hôte standard du stockage SATA. Ce n'est pas de l'USB. Ce n'est pas du NVMe. Ce n'est pas du Thunderbolt.

Ce pour quoi trimforce a été conçu, à l'époque d'OS X 10.10.4 en 2015, c'est une situation précise et aujourd'hui largement historique : quelqu'un ouvre un Mac livré avec un disque à plateaux ou un SSD SATA Apple, y installe un SSD SATA tiers, et découvre que macOS refuse par défaut d'envoyer le Trim à un disque qu'Apple n'a pas qualifié. trimforce outrepasse ce refus. C'est là toute sa raison d'être, et l'avertissement sur les disques qui « may not correctly handle the commands » existe parce qu'en 2015 il y avait des SSD SATA avec des bugs de firmware capables de perdre des données lorsqu'ils étaient trimmés.

Pour un SSD externe dans un boîtier USB, trimforce n'a aucune pertinence. Il n'y a aucun contrôleur AHCI sur le chemin. Le disque se trouve derrière un pont USB mass storage ou UASP, et le fait que le Trim atteigne la flash est décidé par cette puce de pont, pas par un commutateur dans macOS. Pour un disque NVMe, interne ou dans un boîtier Thunderbolt, c'est tout aussi peu pertinent, car NVMe n'est pas AHCI non plus.

Nous nous sommes trompés nous-mêmes. Notre précédent guide de dépannage des SSD externes sur macOS liste sudo trimforce enable sous « Enable TRIM for Third-Party SSDs » dans une section consacrée aux performances des disques externes. Cette recommandation était incorrecte pour les disques externes, et le présent article la remplace. La page de manuel dit ce qu'elle dit depuis 2015 ; nous ne l'avons pas lue assez attentivement. Si vous avez lancé la commande sur la foi de ce conseil, rien de fâcheux n'est arrivé, et rien de bon non plus.

Il y a une raison supplémentaire de ne pas y recourir par réflexe. L'instruction de la page de manuel elle-même d'« use extreme caution » porte sur un vrai mode de défaillance, et la commande exige un redémarrage pour prendre effet. Modifier un réglage de stockage à l'échelle du système, assorti d'une mise en garde documentée sur la perte de données, dans l'espoir qu'il affecte peut-être un disque qu'il ne couvre explicitement pas, est un mauvais calcul quelles que soient les probabilités.

system_profiler SPSerialATADataType renvoie un résultat vide

L'autre vérification universellement répétée est celle-ci :

system_profiler SPSerialATADataType | grep TRIM

Sur un Mac Apple silicon, cela n'affiche rien. Pas « TRIM Support: No ». Absolument rien. Et la raison n'est pas que le Trim est désactivé. C'est que ce type de données n'existe pas sur la machine.

Vous pouvez le confirmer vous-même en une commande :

system_profiler -listDataTypes | grep -i sata

Cela ne renvoie aucune correspondance sur un Mac Apple silicon. Lancer system_profiler -listDataTypes sans le filtre montre ce dont la machine dispose réellement, et sur le Mac que nous avons testé (macOS 26.5.2, build 25F84), les entrées pertinentes pour le stockage comprennent SPNVMeDataType, SPStorageDataType, SPThunderboltDataType et SPUSBHostDataType, entre autres. SPSerialATADataType est absent, parce que les Mac Apple silicon n'ont aucun contrôleur SATA. Le SSD interne est en NVMe, rattaché au SoC, et il n'y a nulle part dans la machine de bus SATA accessible à l'utilisateur.

Ainsi, la vérification de Trim la plus recopiée d'internet interroge un Mac moderne à propos d'un matériel qu'il ne possède pas, obtient une réponse vide, et passe cette réponse vide à grep, qui n'y trouve consciencieusement rien. Aucune erreur, aucun avertissement, aucun code de sortie que quoi que ce soit remarque. Les gens la lancent, voient une sortie blanche, et en tirent la conclusion vers laquelle ils penchaient déjà.

Sur un Mac Intel doté d'un vrai bus SATA, la commande fonctionne bel et bien et signale l'état du Trim pour les périphériques SATA. Si vous en utilisez encore un, elle reste utile pour les disques internes. Elle ne vous a jamais rien dit sur un disque externe connecté en USB, sur aucun Mac.

diskutil ne rapporte pas non plus l'état du Trim

Une troisième variante que vous verrez suggérée consiste à consulter Disk Utility ou diskutil pour connaître l'état du Trim. Il n'y est pas.

diskutil info -all | grep -i trim

Cela ne renvoie rien sur le Mac que nous avons testé. diskutil info -all déverse toutes les propriétés que diskutil connaît sur chaque disque et chaque volume du système, et le Trim n'en fait pas partie. Le panneau d'informations graphique de Disk Utility ne l'affiche pas non plus. Il ne s'agit pas de regarder dans le mauvais volet. diskutil n'expose tout simplement pas l'état du Trim, donc tout guide laissant entendre que vous pouvez l'y lire décrit quelque chose qui n'existe pas.

Les vérifications qui fonctionnent vraiment

Deux méthodes, et celle qui s'applique dépend de la façon dont le disque est connecté.

system_profiler SPNVMeDataType pour les disques internes et NVMe

Pour le SSD interne du Mac, et pour les disques NVMe atteints en Thunderbolt ou USB4 où macOS parle NVMe directement plutôt qu'à travers une couche de traduction SCSI, macOS rapporte bien la prise en charge du Trim et c'est facile à lire :

system_profiler SPNVMeDataType

La sortie est une petite arborescence indentée. Elle commence par NVMExpress:, puis une entrée de contrôleur (sur Apple silicon, Apple SSD Controller:), puis le modèle du disque en tant qu'en-tête. Sous cet en-tête de modèle, sur le Mac que nous avons testé, les clés rapportées apparaissaient dans cet ordre : Capacity, TRIM Support, Model, Revision, Serial Number, Detachable Drive, BSD Name, Partition Map Type, Removable Media, S.M.A.R.T. status, et Volumes.

La ligne qui vous intéresse est la deuxième, TRIM Support. Sur le disque interne du Mac que nous avons testé, elle indiquait Yes. Voilà à quoi ressemble une réponse saine, et cela correspond au résumé qu'Oakley fait de la situation : « Tous les SSD internes Apple bénéficient d'une prise en charge complète du Trim, et les disques externes tiers dotés d'interfaces NVMe devraient en bénéficier aussi. »

Pour n'extraire que cette ligne :

system_profiler SPNVMeDataType | grep -A1 -i "capacity"

Ou lisez simplement toute l'arborescence, assez courte pour que le filtrage n'en vaille guère la peine. Si un boîtier NVMe externe apparaît dans cette sortie, vous êtes en bonne posture, car y apparaître signifie que macOS lui parle en NVMe plutôt qu'en tunnelisant à travers l'USB mass storage.

La limite importante : la plupart des SSD externes USB n'apparaîtront pas du tout dans SPNVMeDataType. Même quand le SSD à l'intérieur du boîtier est un module NVMe, un pont USB le présente au Mac comme un périphérique SCSI sur USB, et il atterrit dans SPUSBHostDataType et SPStorageDataType à la place. Son absence de la liste NVMe n'est pas un verdict sur le fait qu'il soit trimmé ou non. Cela signifie simplement que cette méthode ne peut pas répondre à la question, et qu'il vous faut la seconde.

La méthode du journal au moment du montage

C'est la vérification qui fonctionne pour tout ce qui est formaté en APFS, quelle que soit la connexion, et c'est la méthode de Howard Oakley. Elle fonctionne parce qu'APFS effectue son trimming à un moment précis et observable.

Quand un volume APFS est monté, le gestionnaire d'espace d'APFS balaye le conteneur à la recherche de blocs libres et émet un Trim pour ceux-ci. Il consigne ce qu'il a fait dans le journal unifié, dans des entrées commençant par spaceman_scan_free_blocks. Un conteneur qui a été trimmé affiche le balayage accompagné d'une activité de trim. Un conteneur qui ne l'a pas été affiche le balayage suivi du marqueur (no trims).

Cette seule chaîne de caractères est votre réponse. (no trims) sur un disque qui vient d'être monté et sur lequel il reste de l'espace libre signifie que le Trim n'atteint pas ce disque.

La procédure :

1. Éjectez le disque correctement. Clic droit dans le Finder puis Éjecter, ou utilisez diskutil eject /dev/diskN. Ne tirez pas simplement sur le câble.
2. Débranchez-le physiquement. Attendez quelques secondes.
3. Notez l'heure exacte. À la seconde près, depuis la même horloge que celle du Mac. date dans le Terminal vous la donne avec précision.
4. Rebranchez le disque et attendez que le volume apparaisse dans le Finder et finisse de se monter. Laissez-lui dix à vingt secondes.
5. Lisez le journal pour la fenêtre entourant la connexion.

log show --last 2m --predicate 'senderImagePath CONTAINS[c] "apfs"'

Le prédicat d'Oakley est senderImagePath CONTAINS[c] "apfs", qui capte tout ce qui est émis par le code APFS, quelle que soit la dénomination du sous-système. Si vous avez noté l'heure et voulez une fenêtre plus resserrée, log show accepte aussi des bornes explicites :

log show --start "2026-08-15 14:30:00" --end "2026-08-15 14:30:40" --predicate 'senderImagePath CONTAINS[c] "apfs"'

Si cela ne renvoie strictement rien, ajoutez --info pour inclure les entrées de niveau informatif, puis --debug si vous êtes toujours bredouille. Ces options élargissent le filtre de niveau plutôt que de changer ce qui est recherché.

Puis cherchez dans le résultat spaceman_scan_free_blocks, repérez les entrées nommant le périphérique de votre disque (disk5, disk6, ce que diskutil list indique pour lui), et cherchez le marqueur (no trims). Vérifiez que le numéro de disque correspond bien au disque que vous testez, car votre conteneur de démarrage et tout autre volume APFS monté émettent leurs propres entrées et il est facile de lire la mauvaise.

Pourquoi la durée de fonctionnement ruine cette vérification

Voici le piège, et c'est la raison pour laquelle tant de gens essaient cette méthode et concluent qu'elle ne fonctionne pas.

Les messages de Trim d'APFS ne sont émis qu'au moment du montage. Ils ne sont pas périodiques. Il n'y a pas de battement de cœur horaire. Si un volume a été monté il y a trois semaines et est resté monté, ses entrées de Trim ont été écrites il y a trois semaines et ont disparu depuis longtemps de la fenêtre de rétention du journal.

Nous l'avons testé précisément. Sur un Mac avec 21 jours de fonctionnement continu, l'exécution de :

log show --last 7d --predicate 'senderImagePath CONTAINS[c] "apfs"'

a renvoyé zéro ligne. Pas une seule entrée sur une semaine complète de journaux, sur une machine en parfaite santé avec un SSD interne en parfaite santé qui rapporte TRIM Support: Yes. Le volume de démarrage a été monté au démarrage, trois semaines plus tôt, hors de la fenêtre de rétention, et rien ne s'est monté depuis.

Un résultat vide pour une requête --last 7d est donc dénué de sens. Ce n'est pas la preuve que le Trim est cassé et ce n'est pas la preuve qu'il fonctionne. C'est la preuve que rien n'a été monté récemment. La vérification ne produit une réponse que si vous créez vous-même l'événement de montage, immédiatement avant de lire le journal. Débranchez, notez l'heure, rebranchez, puis lisez. Dans cet ordre, sans délai.

Les outils d'Oakley, si vous préférez éviter le Terminal

Howard Oakley propose deux utilitaires gratuits qui encapsulent cette procédure. Mints inclut une fonction Disk Mount qui capture la fenêtre de journal entourant un montage, et LogUI est un navigateur généraliste du journal unifié qui vous permet d'appliquer le même prédicat via une interface. Les deux sont disponibles auprès de The Eclectic Light Company. Si vous préférez ne pas assembler des invocations de log show à la main, ils font le même travail avec moins de risques de prédicat mal saisi.

Comment mesurer honnêtement lecture contre écriture

Le test du ratio ne vaut que ce que vaut la mesure, et la plupart des mesures faites à la légère sur les SSD produisent des chiffres rassurants qui ne veulent rien dire.

Pourquoi un disque fraîchement effacé a toujours l'air en forme

Si vous effacez un disque et le testez immédiatement, vous obtiendrez sa vitesse nominale. Chaque bloc est effacé, chaque écriture est une opération de programmation propre, et aucun Trim n'est nécessaire pour tenir ce rythme sur la durée d'un benchmark. C'est pourquoi « j'ai lancé un test de vitesse juste après le formatage et tout allait bien » ne vous apprend rien sur le fonctionnement du Trim. Vous avez mesuré la seule condition dans laquelle le Trim est sans objet.

C'est aussi pourquoi le remède décrit plus loin dans cet article semble fonctionner instantanément puis, sur un disque qui n'est toujours pas trimmé, cesse discrètement de fonctionner quelques mois plus tard.

Pour mesurer quelque chose de significatif, le disque doit être dans l'état où le Trim compte : substantiellement utilisé, avec un véritable historique d'écritures et de suppressions derrière lui.

Construire un test qui reflète l'usage réel

Quatre conditions rendent un benchmark honnête pour cet objectif.

Utilisez de gros fichiers. Au moins 8 Go, idéalement plus que le cache SLC du disque, qui sur les disques grand public représente souvent quelques pour cent de la capacité. Les tests sur petits fichiers mesurent la gestion des métadonnées et masquent le comportement de la flash que vous cherchez à observer.

Ayez un disque rempli à peu près à moitié ou plus. Un disque presque vide dispose d'espace libre indépendamment de l'état du Trim. Le problème que vous traquez apparaît quand le contrôleur manque de blocs effacés.

Testez après un gros cycle de suppression. Supprimez quelque chose de volumineux, videz la Corbeille, puis écrivez. C'est exactement le scénario pour lequel le Trim existe : de l'espace que le système de fichiers considère comme libre et que le disque sait ou ne sait pas libre.

Testez le débit soutenu, pas les premières secondes. Tout SSD moderne absorbe la première rafale dans un cache rapide. Observez un transfert pendant trois minutes et regardez la valeur à laquelle il se stabilise.

Une mesure en ligne de commande rustique mais honnête

dd vous donne un chiffre sans rien installer. Écrivez d'abord :

dd if=/dev/zero of=/Volumes/YourDrive/speedtest.bin bs=1m count=8192

Cela écrit 8 Go de zéros. À la fin, dd affiche une ligne de résumé avec le nombre d'octets transférés, le temps écoulé et le débit en octets par seconde. Notez le débit.

Puis videz le cache disque du Mac pour que le test de lecture lise vraiment depuis le disque et non depuis la RAM, et relisez le fichier :

sudo purge
dd if=/Volumes/YourDrive/speedtest.bin of=/dev/null bs=1m

Comparez les deux chiffres de débit. Puis supprimez le fichier de test.

Une réserve : certains contrôleurs de SSD compressent ou dédupliquent une entrée hautement répétitive, et un fichier de zéros purs est le cas le plus facile qui soit, si bien que dd depuis /dev/zero peut flatter un disque. Pour éviter cela, copiez plutôt un gros fichier réel, comme une vidéo, et chronométrez-le. Les alternatives graphiques conviennent très bien aussi. Blackmagic Disk Speed Test fournit un affichage continu que vous pouvez regarder se stabiliser au fil des minutes, ce qui rend la chute liée à l'épuisement du cache facile à voir.

Interpréter le résultat

Calculez la vitesse d'écriture en pourcentage de la vitesse de lecture sur le même disque, même câble, même port, même session.

À 80 % ou plus, rien ne cloche. Les écritures sont normalement un peu plus lentes que les lectures sur la flash et l'ont toujours été.

Entre 40 % et 80 %, vous êtes en territoire ambigu. Cela pourrait être un problème de Trim à un stade précoce, un disque dont le cache est épuisé, un comportement thermique, ou tout simplement les performances de ce modèle. Refaites le test après un gros cycle de suppression et allez exécuter la vérification du journal au montage.

En dessous de 20 %, prenez Oakley au mot et traitez cela comme un problème de Trim. Sa formulation est délibérée : à ce ratio, « vous pouvez être certain qu'il y a un problème de Trim ».

Choix du système de fichiers : APFS, HFS+ et le piège exFAT

Le système de fichiers avec lequel vous avez formaté le disque détermine si le Trim est même tenté, avant que toute question matérielle ne se pose.

exFAT ne trimme pas

C'est la cause la plus évitable de tout ce problème. Oakley l'énonce directement : « APFS et HFS+ trimment normalement un SSD à chaque montage, un disque formaté dans un vieux système de fichiers PC comme ExFAT a très peu de chances d'être trimmé du tout. »

exFAT est le format dans lequel les disques sont livrés, parce que c'est le seul que macOS et Windows lisent et écrivent tous les deux sans logiciel supplémentaire. C'est aussi ce que les gens choisissent délibérément quand ils doivent déplacer un disque entre un Mac et un PC. Et cela signifie que le disque ne recevra jamais de commande Trim de macOS, quel que soit le boîtier, quel que soit le mode de connexion, quoi que rapporte n'importe quelle vérification.

Si votre SSD externe lent est en exFAT, vous avez trouvé votre réponse et vous n'avez pas besoin de faire la vérification du journal. Il n'y aura aucune entrée de montage APFS pour lui, puisqu'il n'y a aucun conteneur APFS à balayer.

Le compromis multiplateforme

Le compromis est réel et il n'y a pas de réponse gratuite, alors soyez explicite sur le camp que vous choisissez.

Format	Trim sur macOS	Compatibilité Windows	Idéal pour
APFS	Oui, à chaque montage	Pas nativement ; nécessite un logiciel tiers	Disques réservés au Mac, Time Machine sur macOS récent, tout ce qui est sensible aux performances
HFS+ (Mac OS étendu)	Oui, à chaque montage	Pas nativement ; nécessite un logiciel tiers	Mac plus anciens, flux de travail hérités, disques devant fonctionner avec de très vieux systèmes
exFAT	Non	Oui, nativement	Le vrai partage multiplateforme, quand vous acceptez le coût en performances

Si vous avez réellement besoin d'un disque qui se branche à la fois sur un Mac et sur une machine Windows, exFAT est le choix pragmatique et vous devez accepter que ses performances en écriture se dégraderont avec l'âge. Atténuez cela en gardant le disque bien en deçà de sa capacité et en le reformatant de temps en temps plutôt que jamais. Mais si l'accès multiplateforme est quelque chose dont vous pourriez avoir besoin un jour plutôt que quelque chose que vous faites toutes les semaines, formatez en APFS. Vous pourrez toujours copier des fichiers via le réseau, et un disque qui reste rapide pendant des années vaut mieux qu'une commodité hypothétique.

HFS+ est trimmé, mais ses jours sont comptés

HFS+ est toujours trimmé et fonctionne toujours. Ce n'est cependant pas un bon choix à long terme sur un Mac, et le HFS+ chiffré en particulier est sur une trajectoire d'abandon. Si vous utilisez un disque externe en HFS+ et que vous songez de toute façon à le reformater, c'est le bon moment pour passer à APFS. Notre guide sur la conversion des volumes HFS+ chiffrés vers APFS couvre la migration et ses implications pour Time Machine.

Choix de la connexion : ponts USB contre Thunderbolt et NVMe

Le système de fichiers est nécessaire mais pas suffisant. Un disque APFS a encore besoin que la commande Trim atteigne physiquement le contrôleur de flash, et c'est là que le boîtier entre en jeu.

Ce que la puce de pont doit faire

Un SSD externe USB n'est pas un disque qui parle directement à votre Mac. À l'intérieur du boîtier se trouve une puce de pont qui traduit entre l'USB et ce que parle le module de stockage, SATA ou NVMe. macOS envoie les commandes de stockage sur USB sous forme de SCSI, typiquement via UASP (USB Attached SCSI Protocol), et l'équivalent SCSI du Trim est UNMAP.

La commande doit donc survivre à une chaîne : APFS décide de trimmer, macOS émet un UNMAP sur USB, la puce de pont le reçoit, la puce de pont le traduit en un TRIM SATA ou un Deallocate NVMe, et le module de stockage l'exécute. Si le pont n'implémente pas cette traduction, la commande est perdue. Silencieusement. Aucune erreur n'est remontée où que ce soit, ce qui est précisément pourquoi c'est difficile à diagnostiquer et pourquoi la vérification du journal est la seule lecture fiable de la situation.

La situation généralement rapportée, cohérente entre la documentation des fabricants et les tests communautaires, est que la transmission du Trim à travers les ponts USB est inconstante : certains ponts font passer UNMAP, beaucoup non, et cela varie selon la puce et la révision du firmware plutôt que selon la marque du disque. Thunderbolt et les chemins NVMe natifs sont la voie fiable, car il n'y a aucune couche de traduction où perdre la commande. Le résumé d'Oakley, de nouveau : « Tous les SSD internes Apple bénéficient d'une prise en charge complète du Trim, et les disques externes tiers dotés d'interfaces NVMe devraient en bénéficier aussi. » Notez le « devraient », qui est de lui et qui fait un travail honnête.

Les vieux disques SATA sont les plus exposés. Comme le dit Oakley : « Les disques plus lents dotés d'interfaces SATA sont ceux qui ont le plus de chances de ne pas prendre en charge le Trim. » Si votre disque externe est un SSD SATA dans un caddy USB, ce qui décrit beaucoup de disques assemblés à partir d'un SSD 2,5 pouces de récupération, c'est la configuration la plus à risque qui soit.

Apple ne publie aucune liste de compatibilité

Disons-le clairement, car cela change votre façon d'acheter : Apple ne publie aucune liste des boîtiers externes prenant en charge le Trim sur macOS. Il n'y a pas de document d'assistance, pas de page de matériel qualifié, pas d'API qui le rapporte pour les disques connectés en USB, et aucune indication dans Informations Système. Apple n'a jamais documenté le comportement du Trim pour le stockage externe, tout simplement.

Cela signifie qu'il n'existe aucun moyen faisant autorité de savoir si un boîtier donné transmettra le Trim avant de l'acheter. Le marketing des fabricants n'est pas non plus un guide fiable, car la plupart des vendeurs de boîtiers ne mentionnent le Trim ni dans un sens ni dans l'autre. La seule façon de le découvrir est de l'acheter, de le formater en APFS et d'exécuter la vérification du journal au montage.

C'est véritablement insatisfaisant, et quiconque vous affirme qu'un chipset précis prend ou ne prend définitivement pas en charge le Trim sur macOS avance plus que ce que les preuves disponibles permettent. Les révisions de firmware des puces diffèrent, les vendeurs de boîtiers changent les composants internes sans changer les références, et le comportement de macOS lui-même a évolué au fil des versions. Testez le disque que vous possédez.

Ce que cela implique au moment d'acheter

En l'absence de liste de compatibilité, privilégiez les configurations où le problème de traduction n'existe pas. Un boîtier NVMe Thunderbolt ou USB4 supprime le pont de l'équation et offre au passage un débit considérablement plus élevé. Si vous vous penchez déjà sur le volet connectique de votre installation, notre guide d'achat des docks Thunderbolt 5 couvre ce que la génération actuelle de matériel délivre réellement.

Acheter un SSD portable intégré chez un grand fabricant, plutôt que d'en assembler un à partir d'un caddy et d'un disque de récupération, est généralement moins risqué, car le fabricant a choisi et validé le pont pour ce module précis. Pas une garantie, mais une variable de moins.

Et quoi que vous achetiez, testez-le la première semaine, tant que le renvoyer est encore facile. Formatez-le en APFS, copiez-y des données, supprimez-en, éjectez, reconnectez et lisez le journal. Deux minutes, et vous savez.

Le remède : effacer et reformater

Il n'existe aucune commande pour trimmer un disque à la demande

Les gens cherchent une commande « trimme mon disque maintenant » et elle n'existe pas. macOS n'expose aucun moyen accessible à l'utilisateur d'émettre un Trim sur un volume à la demande. trimforce, comme établi, bascule une politique système pour les disques tiers connectés en AHCI et ne s'applique pas ici. Disk Utility n'a pas de telle fonction. diskutil n'a pas de tel verbe.

Vous verrez peut-être des suggestions consistant à remplir le disque avec un fichier gigantesque puis à le supprimer. Cela n'aide pas, et sur un disque qui ne reçoit pas de Trim, cela aggrave les choses en écrivant davantage de données que le contrôleur considérera comme valides.

Oakley est sans ambiguïté sur ce qui reste : « Le seul traitement curatif consiste à reformater entièrement le SSD et à voir si cela restaure une vitesse d'écriture normale. »

Effacer un disque reconstruit la table de partition et le système de fichiers à partir de zéro. Sur un disque dont le contrôleur en tient compte, l'effacement lui-même ramène de fait les blocs à un état libre, et le disque revient à pleine vitesse. C'est pourquoi la solution est réelle. C'est aussi pourquoi elle est temporaire si le chemin de Trim sous-jacent est toujours cassé, car vous avez remis le compteur à zéro sans réparer le mécanisme.

Sauvegardez vos données d'abord, correctement

L'effacement détruit tout ce qui se trouve sur le disque, alors avant de toucher à Disk Utility, copiez tout ailleurs et vérifiez. Pas « la copie s'est terminée », mais ouvrez réellement plusieurs fichiers de la copie, y compris de gros fichiers, et confirmez qu'ils sont intacts. Les lectures sont encore rapides sur ce disque, donc cette étape va vite, ce qui est la petite consolation de ce mode de défaillance.

Si le disque contient votre unique exemplaire de quelque chose, faites-en d'abord une seconde copie ailleurs. Un disque avec un problème de Trim n'est pas défaillant et a peu de chances de mourir pendant un effacement, mais n'ayez jamais un seul exemplaire de ce qui compte pour vous. Et si le disque est une destination Time Machine, vous êtes sur le point de jeter votre historique de sauvegardes : lisez la section Time Machine ci-dessous avant de décider.

Réaliser l'effacement

Utilisez Disk Utility, et modifiez d'abord un réglage par défaut.

Ouvrez Disk Utility, puis choisissez Présentation → Afficher tous les appareils. C'est important. Sans cela, Disk Utility n'affiche que les volumes, et effacer un volume laisse en place le conteneur et le schéma de partition. Vous voulez effacer le périphérique physique, c'est-à-dire l'entrée de premier niveau dans la barre latérale, portant le nom du modèle du disque.

Sélectionnez ce périphérique de premier niveau, cliquez sur Effacer, et réglez :

• Schéma : Table de partition GUID
• Format : APFS, sauf si vous avez une raison précise de choisir exFAT

N'utilisez pas le curseur des options de sécurité qui réécrit plusieurs fois sur le disque. Sur un SSD, c'est lent, cela écrit une quantité énorme de données sans aucun bénéfice, et cela va exactement à l'encontre de l'état des blocs que vous cherchez à restaurer.

L'équivalent en ligne de commande, si vous préférez :

diskutil list
diskutil eraseDisk APFS DriveName GPT /dev/diskN

Lancez diskutil list en premier et lisez attentivement la sortie pour identifier le bon périphérique. eraseDisk sur le mauvais diskN détruit le mauvais disque et il n'y a aucune demande de confirmation.

À quoi s'attendre ensuite

Mesurez-le immédiatement et il sera rapide. Cela prouve que la flash est en bonne santé, et rien de plus.

Le vrai test, c'est ce qui se passe dans les mois qui suivent. Recopiez vos données, utilisez le disque normalement, et refaites le test du ratio dans six à huit semaines, après que le disque a traversé de vrais cycles de suppression et de réécriture. Si la vitesse d'écriture tient, le Trim atteint probablement le disque et c'était un incident isolé. Si elle se dégrade à nouveau selon la même courbe, le boîtier ne transmet pas le Trim et le reformatage est une opération de maintenance que vous ferez périodiquement, pas une solution.

À ce stade, la décision devient économique. Un reformatage périodique est tolérable pour un disque de travail que vous pouvez reconstruire en une heure. Ce n'est pas tolérable pour une archive de travail. Si le disque compte, remplacer le boîtier par une unité Thunderbolt ou NVMe et tester celle-ci est la réponse durable.

Prévention : éviter qu'un disque n'en arrive là

Laissez de la marge

L'habitude la plus efficace. Un disque maintenu à 70 % ou moins dispose d'espace logique libre avec lequel le contrôleur peut travailler même en l'absence de Trim, car les blocs jamais écrits restent effacés. Un disque qui a été poussé à 98 % de remplissage a vu pratiquement chacun de ses blocs sollicité et n'a plus aucune marge.

Cela vaut aussi pour le stockage interne, où la même physique gouverne le SSD de démarrage, même si là le Trim fonctionne à coup sûr. Notre guide de gestion du stockage explique comment trouver et récupérer de l'espace sur un Mac qui approche de la saturation.

Évitez les flux de travail qui remplissent à ras bord

Certaines habitudes sont bien plus dures pour un disque que d'autres. Remplir un disque à ras bord avec des rushes de caméra, tout décharger, puis le remplir de nouveau est le pire cas : maximum de blocs sollicités, dépendance maximale au Trim, répété indéfiniment. Les professionnels des médias rencontrent ce mode de défaillance bien plus tôt que les utilisateurs ordinaires, et supposent souvent que le disque s'use alors que ce n'est pas le cas.

Si cela décrit votre travail, utilisez soit un disque dont vous avez vérifié qu'il transmet le Trim, soit prévoyez un cycle de reformatage entre les projets. Alterner entre deux disques et reformater chacun après déchargement est un mode de fonctionnement raisonnable, et cela coûte un effacement par projet.

Choisissez le boîtier délibérément

Cela mérite d'être répété comme prévention plutôt que comme diagnostic : c'est le boîtier qui décide, pas le module SSD à l'intérieur ni la marque sur la boîte. Choisissez Thunderbolt ou NVMe natif quand la charge de travail le justifie, et testez ce que vous choisissez dès la première semaine.

Retestez de temps en temps

La vérification du journal au montage prend deux minutes. L'exécuter une fois par an sur vos disques externes importants, ou après toute mise à niveau majeure de macOS, permet de repérer un changement de comportement avant qu'il ne vous coûte un mois de transferts lents. Notez le résultat quelque part. Savoir qu'un disque donné était clean en mars est un contexte utile en décembre.

Destinations Time Machine et clones amorçables

Pourquoi Time Machine est un pire cas

Une destination Time Machine est proche du scénario de stress maximal pour le Trim. Elle se remplit jusqu'à saturation par conception, puis commence à supprimer les instantanés les plus anciens pour faire de la place, puis écrit à nouveau dans cet espace récupéré, en boucle, indéfiniment. C'est un cycle continu de grosses suppressions suivies de grosses écritures, c'est-à-dire précisément le schéma qui dépend du Trim pour rester rapide.

Sur une destination SSD qui ne reçoit pas de Trim, les sauvegardes deviennent de plus en plus lentes au fil des mois. Le symptôme que les gens rapportent, c'est que des sauvegardes Time Machine qui se terminaient en quelques minutes durent maintenant des heures, ou semblent se figer pendant « Préparation de la sauvegarde » ou pendant l'écriture. Il est facile d'incriminer Time Machine, et Time Machine a bien assez de vrais problèmes qu'il vaut la peine d'écarter séparément, ce que notre guide de dépannage de Time Machine couvre en détail. Mais si la destination est un SSD et que les lectures depuis celui-ci sont toujours rapides tandis que les écritures traînent, envisagez le Trim avant de passer un après-midi sur les réglages propres à Time Machine.

La complication, c'est qu'effacer une destination Time Machine détruit votre historique de sauvegardes. Il n'y a aucun moyen de reformater un disque en conservant ses instantanés. Vos options sont d'accepter la perte de l'historique et de démarrer une nouvelle sauvegarde, ou de mettre en place une nouvelle destination sur un autre disque et de retirer l'ancien une fois la nouvelle sauvegarde établie. Pour la plupart des gens, la seconde option vaut le prix d'un disque, car une sauvegarde sans historique est bien moins utile qu'une sauvegarde avec des mois de versions.

Une remarque sur le choix du matériel pour les sauvegardes en particulier : c'est un cas où un disque dur classique n'est pas une mauvaise réponse. Les disques à plateaux n'ont aucun problème de bloc d'effacement et aucun besoin de Trim. Ils sont plus lents sur le papier, mais pour une sauvegarde incrémentale nocturne c'est souvent sans importance, et leur comportement ne se dégrade pas au fil des années de cycles de remplissage et de suppression.

Clones amorçables et volumes de démarrage externes

Les clones amorçables se comportent de façon similaire. Le logiciel de clonage réécrit de grandes quantités de données à chaque exécution, donc si la destination n'est pas trimmée, les temps de clonage augmentent régulièrement. Un avantage ici, c'est qu'une destination de clone est montée et démontée souvent, ce qui rend les entrées de journal au montage triviales à générer : éjectez, reconnectez, lisez le journal, terminé en moins d'une minute.

Si vous démarrez macOS depuis un disque externe comme installation de travail plutôt que comme outil de dépannage, les enjeux sont plus élevés, car chaque écriture système passe par le même chemin dégradé. C'est un argument fort en faveur d'un boîtier NVMe Thunderbolt plutôt qu'un caddy USB, spécifiquement pour les disques de démarrage.

Résolution des problèmes courants

La vérification du journal ne renvoie strictement rien

Problème : Vous lancez log show avec le prédicat APFS et obtenez zéro ligne, alors même que le disque est connecté.

Solution : Vous avez presque certainement lu le journal sans créer d'abord un événement de montage, ou trop longtemps après. Les entrées ne sont écrites que lorsqu'un volume est monté. Éjectez le disque, débranchez-le physiquement, notez l'heure avec date, rebranchez, attendez quinze secondes que le volume apparaisse dans le Finder, et seulement alors lancez log show --last 2m. Si c'est toujours vide, ajoutez --info puis --debug pour élargir le filtre de niveau. Si c'est toujours vide et que le disque s'est bien monté, vérifiez que le disque est effectivement en APFS : un disque exFAT ne produit aucune entrée APFS, puisqu'il n'y a aucun conteneur APFS à balayer.

system_profiler SPSerialATADataType n'affiche rien

Problème : La vérification du Trim que tous les sites recommandent ne produit aucune sortie, et vous ne pouvez pas savoir si cela signifie que le Trim est désactivé.

Solution : Cela ne signifie ni l'un ni l'autre. Sur un Mac Apple silicon, ce type de données n'existe pas. Confirmez avec system_profiler -listDataTypes | grep -i sata, qui ne renverra rien non plus. Utilisez system_profiler SPNVMeDataType pour les disques internes et NVMe, et la méthode du journal au montage pour tout le reste. Il n'existe aucune interprétation du résultat SATA vide qui ait un sens sur ces machines.

Vous avez lancé sudo trimforce enable et rien n'a changé

Problème : Vous avez activé trimforce, redémarré comme demandé, et le disque externe est exactement aussi lent qu'avant.

Solution : C'est le résultat attendu. trimforce agit sur les disques tiers connectés à un contrôleur AHCI (SATA), selon sa propre page de manuel, et votre disque externe USB ou NVMe n'en est pas un. Rien n'a été cassé en le lançant et rien n'a été réparé. Lancez man trimforce et lisez la DESCRIPTION vous-même si vous voulez confirmation. Passez à la vérification du journal au montage pour découvrir ce qui se passe réellement.

Le disque affiche TRIM Support: Yes mais les écritures restent lentes

Problème : system_profiler SPNVMeDataType rapporte la prise en charge du Trim pour le disque, et pourtant les performances en écriture sont médiocres.

Solution : Que la prise en charge du Trim soit rapportée signifie que le disque et le chemin annoncent cette capacité. Cela ne confirme pas que le trimming a lieu sur ce volume, ce que mesure justement la vérification du journal au montage. Exécutez cette vérification ensuite. Écartez aussi les causes non liées au Trim : vérifiez la vitesse de lien négociée dans Informations Système, changez de câble, testez sur un autre port, et lancez un transfert soutenu de trois minutes pour voir si vous avez affaire à un épuisement de cache ou à une limitation thermique plutôt qu'à une pénurie de blocs.

Les vitesses sont bonnes pendant les trente premières secondes puis s'effondrent

Problème : Les grosses copies démarrent à pleine vitesse puis chutent de 70 % ou plus en cours de route, à chaque fois.

Solution : C'est généralement le cache d'écriture SLC qui se remplit plutôt qu'un problème de Trim, et c'est un comportement normal sur les disques grand public, même si un disque privé de Trim affichera un plancher plus bas après la chute. Distinguez-les en testant après une période d'inactivité disque sous tension : les ralentissements liés au cache disparaissent une fois que le disque a eu le temps de vider son cache, la privation de Trim non. Vérifiez aussi la température du boîtier, car une puce de pont ou un module NVMe brûlant se bride fortement et donne exactement la même impression de l'extérieur.

Les petits fichiers sont lents mais les gros fichiers sont rapides

Problème : Copier un dossier de milliers de petits fichiers prend bien plus de temps que copier un seul fichier de même taille totale.

Solution : Ce n'est pas un problème de Trim. La surcharge par fichier domine les transferts de petits fichiers, et l'indexation Spotlight ou un logiciel de sécurité analysant chaque fichier à son arrivée aggrave considérablement les choses. Testez avec un seul gros fichier pour obtenir un chiffre de débit propre. Si les écritures de gros fichiers sont normales, la flash va bien. Pour réduire la pénalité sur les petits fichiers, envisagez d'exclure le disque de Spotlight dans Réglages Système → Siri et Spotlight → Confidentialité Spotlight, ou de transférer le dossier sous forme d'une archive unique.

L'effacement a réglé le problème, mais seulement pour quelques mois

Problème : Un reformatage a restauré la pleine vitesse, et maintenant, quelques mois plus tard, les écritures se sont dégradées à nouveau selon la même courbe.

Solution : Le reformatage a traité le symptôme. La récidive vous indique que le Trim n'atteint véritablement pas ce disque, donc la réserve de blocs se vide à nouveau dès que vous reconstituez un historique d'écritures et de suppressions. Confirmez avec la vérification du journal au montage sur le disque reformaté, en cherchant (no trims). Si c'est confirmé, vos options réalistes sont d'accepter le reformatage périodique comme opération de maintenance, ou de déplacer le module SSD dans un boîtier Thunderbolt ou NVMe et de tester ce chemin. Aucun réglage logiciel ne changera l'issue.

Le disque se déconnecte aussi de façon aléatoire

Problème : En plus des écritures lentes, le disque s'éjecte tout seul, ou vous recevez des notifications répétées « Disque non éjecté correctement ».

Solution : Traitez-les comme deux défauts distincts et corrigez d'abord les déconnexions, car une connexion instable rend toute mesure peu fiable et peut corrompre le volume en pleine écriture. La déconnexion est généralement un problème d'alimentation ou de bus plutôt qu'un problème de flash : disques alimentés par le bus sur un hub, mise en veille agressive du boîtier, ou câble limite. Notre guide sur les erreurs de disque non éjecté correctement et l'alimentation USB couvre les causes précises. Une fois que le disque reste connecté de façon fiable, revenez refaire le test du ratio.

FAQ

Est-ce que sudo trimforce enable aide un SSD externe USB ?

Non. Sa page de manuel indique qu'il active le Trim pour les disques tiers connectés à un contrôleur AHCI, c'est-à-dire l'interface SATA. Un disque externe USB atteint le Mac via un pont USB, et un disque NVMe n'est pas non plus de l'AHCI. La commande s'applique aux SSD SATA tiers installés à l'intérieur de Mac plus anciens, et à rien d'autre.

Pourquoi system_profiler SPSerialATADataType ne renvoie-t-il rien sur mon Mac ?

Parce que les Mac Apple silicon n'ont aucun contrôleur SATA, donc ce type de données n'existe pas sur eux. Confirmez-le vous-même avec system_profiler -listDataTypes | grep -i sata, qui ne renvoie aucune correspondance. La sortie vide n'est pas un rapport indiquant que le Trim est désactivé. C'est l'absence complète de la catégorie matérielle.

Puis-je vérifier l'état du Trim dans Disk Utility ou avec diskutil ?

Non. diskutil info -all | grep -i trim ne renvoie rien, parce que diskutil n'expose pas l'état du Trim parmi les propriétés qu'il rapporte, et le panneau d'informations de Disk Utility ne l'affiche pas non plus. Les guides qui laissent entendre le contraire décrivent quelque chose que macOS ne fournit pas. Utilisez plutôt system_profiler SPNVMeDataType ou la vérification du journal au montage.

Comment distinguer un problème de Trim d'un mauvais câble ?

Comparez la vitesse de lecture à la vitesse d'écriture sur le même disque, dans la même session, avec un seul fichier d'au moins 8 Go. Un problème de câble ou de port ralentit les deux sens dans une proportion similaire. Un problème de Trim laisse les lectures à pleine vitesse tandis que les écritures s'effondrent. Le seuil de Howard Oakley est des écritures à 20 % ou moins des lectures.

Effacer le disque corrigera-t-il définitivement les écritures lentes ?

Cela restaure immédiatement la pleine vitesse, car l'effacement ramène la flash dans un état où les écritures n'ont besoin d'aucun cycle d'effacement préalable. La durée de cette amélioration dépend de savoir si le Trim atteint le disque en usage normal. Si c'est le cas, le problème ne devrait pas revenir. Si ce n'est pas le cas, attendez-vous à la même dégradation en quelques mois.

exFAT est-il vraiment si mauvais pour un SSD externe sur un Mac ?

Pour les performances dans la durée, oui. exFAT ne trimmera pas le disque, donc un SSD en exFAT est assuré de se dégrader à mesure qu'il accumule un historique d'écritures, quel que soit le boîtier ou la connexion. Ne choisissez exFAT que si vous avez réellement besoin d'un accès Windows natif, et si c'est le cas, gardez le disque bien en deçà de sa capacité et reformatez-le périodiquement.

Conclusion

Un SSD externe qui écrit lentement tout en lisant à pleine vitesse vous a dit ce qui n'allait pas avant même que vous ne lanciez la moindre commande. Cette asymétrie est l'empreinte d'un disque à court de blocs pré-effacés et à qui personne ne dit quels blocs il peut récupérer.

Si c'est difficile à diagnostiquer, ce n'est pas parce que le mécanisme est subtil. C'est parce que les deux vérifications sur lesquelles internet s'est mis d'accord échouent toutes les deux en silence sur un Mac moderne. system_profiler SPSerialATADataType interroge une catégorie matérielle qu'Apple silicon ne possède pas et renvoie un résultat vide. sudo trimforce enable bascule une politique pour les disques SATA connectés en AHCI et ne peut rien pour un disque externe USB, comme le dit sa propre page de manuel dès son premier paragraphe. Aucune des deux ne signale d'erreur. C'est ce silence qui maintient les mauvais conseils en circulation, et c'est pourquoi nous les avons nous-mêmes répétés dans un guide antérieur.

Ce qui fonctionne est plus étroit. Pour les disques internes et les disques externes NVMe, system_profiler SPNVMeDataType rapporte directement TRIM Support. Pour tout ce qui est formaté en APFS, éjectez le disque, notez l'heure, rebranchez-le, attendez qu'il se monte, et lisez le journal unifié à la recherche d'entrées spaceman_scan_free_blocks, en cherchant le marqueur (no trims). Faites-le dans cet ordre et sans délai, car ces entrées sont écrites au moment du montage et nulle part ailleurs. Sur la machine que nous avons testée, avec trois semaines de fonctionnement continu, une semaine complète de journaux n'en contenait aucune.

Si la vérification revient mauvaise, le remède est un effacement complet et un reformatage, et aucune commande accessible à l'utilisateur ne s'y substitue. La tenue de cette solution dépend du boîtier, et comme Apple ne publie aucune liste de compatibilité pour le Trim sur les boîtiers externes, le seul moyen de le savoir est de reformater, d'utiliser le disque pendant deux mois et de mesurer à nouveau. S'il se dégrade selon la même courbe, le boîtier perd la commande, et la réponse durable est un chemin Thunderbolt ou NVMe natif plutôt qu'un quelconque changement logiciel de votre part.

Faites trois choses cette semaine. Lancez le test du ratio sur votre disque externe principal avec un gros fichier dans chaque sens. Si le ratio semble anormal, faites la vérification du journal au montage pendant que le disque est encore dans son état dégradé, afin d'apprendre quelque chose plutôt que de simplement le réparer. Et formatez vos disques externes réservés au Mac en APFS plutôt qu'en exFAT, car cette seule décision détermine si le Trim est même tenté.

Lectures complémentaires : Guide de dépannage des SSD externes sur macOS · Guide complet de dépannage de Time Machine