Un câble USB-C qui ressemble à tous les autres peut silencieusement griller votre laptop à 1500€. Pas de fumée, pas d’avertissement, juste un composant qui lâche après quelques semaines d’utilisation intensive. Ce scénario catastrophe n’est pas hypothétique : des milliers de câbles non-certifiés circulent sur les marketplaces, vendus moins de 5€ avec de belles photos et des descriptions techniques inventées de toutes pièces. La bonne nouvelle, c’est qu’on peut filtrer ça côté logiciel, sans acheter le moindre appareil de mesure.
À retenir
- Des milliers de câbles USB-C contrefaits sans protection thermique circulent sur les marketplaces à moins de 5€
- Votre noyau Linux collecte déjà les données secrètes que le câble refuse de révéler
- La vérification logicielle a ses limites, mais c’est une première ligne de défense critique
Pourquoi l’USB-C cache un vrai problème de fiabilité
L’USB-C a réalisé quelque chose de remarquable : unifier les connecteurs. Un seul port pour la charge, la vidéo, le transfert de données, parfois même le réseau. Mais cette polyvalence a un coût souvent sous-estimé : la complexité du protocole Power Delivery (USB-PD) qui se cache derrière. Là où un vieux câble micro-USB passait juste du courant, un câble USB-C certifié doit embarquer une puce électronique, un marqueur E (E-Marker), capable de communiquer ses capacités au chargeur. Quel voltage maximum ? Quelle intensité ? Quel profil de puissance ?
Un câble sans marqueur E va fonctionner… dans la plupart des cas. Jusqu’au jour où votre chargeur 100W essaie de pousser une puissance que le câble n’est physiquement pas conçu pour gérer. Les câbles low-cost omettent régulièrement cette puce pour gratter quelques centimes de marge. Ce n’est pas visible à l’œil nu. La seule façon de le savoir, c’est d’interroger le câble lui-même.
Et votre système d’exploitation le peut. C’est là que ça devient intéressant.
Ce que le script fait concrètement
L’idée derrière l’approche en ligne de commande, c’est d’exploiter les informations que le noyau Linux (ou macOS via des outils tiers) collecte déjà sur vos périphériques USB-C connectés. Sous Linux, le sous-système USB Power Delivery expose ses données dans /sys/class/typec/. Chaque port, chaque câble connecté, chaque adaptateur a son propre répertoire avec des fichiers lisibles en clair.
Un script shell basique peut parcourir ces répertoires, lire les fichiers identity, current_pdo ou encore les informations VDO (Vendor Defined Objects) et les interpréter pour vous. Concrètement, voici ce qu’il vérifie :
- Présence ou absence d’un marqueur E (E-Marker chip)
- Capacité annoncée en ampères et en volts
- Cohérence entre les profils de puissance déclarés
- Identité du fabricant si le câble la communique
Un câble certifié pour 5A/20V (soit 100W) doit avoir un marqueur E selon les spécifications USB-IF. Si votre script trouve un câble qui prétend supporter cette puissance sans marqueur E déclaré, c’est un signal d’alarme clair.
Comment l’exécuter sur votre machine
Avant de coller la moindre commande dans votre terminal, vérifiez que votre machine tourne bien sur Linux avec un noyau récent (5.4 minimum, idéalement 6.x) et que vous avez un port USB-C qui gère le Power Delivery. Les vieux ThinkPads avec uniquement des ports USB-A ne sont pas concernés, mais si vous lisez cet article, vous avez probablement un laptop récent.
Commencez par explorer ce que votre système voit déjà :
ls /sys/class/typec/
Si vous obtenez des répertoires comme port0 ou port0-partner, votre noyau supporte bien l’introspection USB-C. Le partner correspond à ce qui est branché côté câble. Pour lire l’identité du câble (si elle est disponible) :
cat /sys/class/typec/port0-partner/identity/product
Un script complet va automatiser cette lecture sur tous les ports disponibles, formater la sortie pour la rendre lisible et lever une alerte colorée si une incohérence est détectée. Les versions qu’on trouve sur GitHub (cherchez « usb-c cable checker linux script ») font exactement ça en moins de cinquante lignes de bash. Certaines intègrent même une vérification contre une base de VID/PID (Vendor ID / Product ID) de câbles connus pour être problématiques.
Sous macOS, la situation est plus compliquée. Apple verrouille l’accès direct à ces informations, mais l’utilitaire system_profiler SPUSBDataType donne une partie des infos. Des outils tiers comme USBMap poussent l’analyse plus loin, même si on reste loin de la granularité qu’offre Linux.
Ce que le script ne peut pas faire (et c’est important)
Soyons honnêtes : cette approche logicielle a des limites réelles. Elle repose entièrement sur ce que le câble annonce lui-même. Un câble vraiment mal conçu, avec une puce E-Marker présente mais programmée avec de fausses données, trompera le script comme il trompe votre chargeur. Ce cas existe, même s’il est moins fréquent que les câbles sans marqueur du tout.
Le script ne mesure pas la résistance des fils, ne détecte pas les conducteurs sous-dimensionnés, ne teste pas la qualité des soudures. Pour ça, il faudrait du matériel dédié, comme les testeurs USB-C portables qui coûtent entre 20 et 80€ et affichent en temps réel la puissance qui transite dans le câble. L’approche logicielle est une première ligne de défense, pas un audit complet.
Pensez-y comme le test de fumée d’un développeur : si le script détecte une anomalie, le câble est suspect et mérite d’être écarté immédiatement. S’il passe, c’est rassurant mais pas une garantie absolue.
La vraie question que ça soulève, c’est celle de la responsabilité des plateformes de vente. On peut scripter des vérifications, acheter des testeurs, lire les spécifications USB-IF en version PDF de 400 pages… ou simplement se demander pourquoi des câbles dont la mise en conformité tient en quelques cents de composants supplémentaires continuent de trouver acheteurs. La réglementation européenne pousse vers plus de certification obligatoire, et on verra dans les prochaines années si ça change vraiment le marché ou juste le discours marketing.