Lorsqu'un élève branche un ESP32, une carte compatible Arduino ou un contrôleur robotique personnalisé sur un ordinateur portable de l'école et que rien ne se passe, la panne ne vient presque jamais du microcontrôleur lui-même. Dans pratiquement toutes les salles informatiques scolaires, le problème provient de l'une de ces deux causes simples : un environnement d'exploitation standard (SOE) Windows verrouillé dépourvu de pilotes de pont USB-UART, ou un lot de câbles USB de charge seule mélangé dans les bacs de rangement de la classe.

1. Le problème de conversion matérielle : de l'USB à l'UART

La plupart des microcontrôleurs d'entrée de gamme (comme les cartes ESP32 standard, l'ESP8266 et les clones de l'Arduino Uno) ne communiquent pas directement via l'USB natif. Ils utilisent plutôt des broches série matérielles (UART) reliées à une puce de pont intermédiaire soudée sur la carte de développement. Cette puce convertit les données série en paquets USB qu'un ordinateur hôte peut interpréter comme un port COM virtuel.

Les deux puces de pont les plus courantes sur le matériel éducatif sont :

• WCH CH340 / CH341 : la puce omniprésente que l'on retrouve sur les cartes économiques ESP32 et compatibles Arduino.
• Silicon Labs CP2102 / CP2104 : courante sur les modules robotiques intermédiaires, NodeMCU et les modules de développement ESP32.
• FTDI FT232R : présente sur les contrôleurs robotiques aux spécifications plus élevées et les cartes d'interface industrielle.

Les ordinateurs portables récents utilisés à la maison sous Windows 11, disposant de tous les droits d'administrateur et d'un accès Internet non restreint, téléchargent souvent ces pilotes automatiquement via Windows Update dès la première connexion d'une carte. En environnement scolaire, ce processus automatisé échoue presque systématiquement.

2. Pourquoi les déploiements en salle informatique bloquent les périphériques série

Les environnements informatiques scolaires fonctionnent sous des stratégies de groupe (GPO) strictes ou des profils de gestion des appareils mobiles (MDM) tels que Microsoft Intune. Ces configurations empêchent délibérément les comptes d'élèves sans privilèges d'installer des pilotes de périphériques tiers ou en mode noyau.

Lorsqu'un élève se connecte avec des privilèges d'utilisateur standard et branche un microcontrôleur basé sur le CH340, Windows identifie un périphérique inconnu sous Autres périphériques dans le Gestionnaire de périphériques (souvent simplement nommé USB-Serial ou USB2.0-Serial avec un triangle d'avertissement jaune). Comme le profil de l'élève ne peut pas écrire de fichiers de pilotes dans System32\drivers, la carte ne se voit jamais attribuer de port COM virtuel, et les environnements de développement intégrés (IDE) en ligne ou l'environnement Arduino signalent qu'aucun appareil n'est connecté.

3. La solution administrateur : le déploiement silencieux des pilotes

Pour résoudre ce problème à l'échelle d'une salle informatique ou d'un chariot d'ordinateurs portables, il est nécessaire de déployer les packages de pilotes de manière silencieuse au niveau de la machine (contexte SYSTEM), plutôt que de compter sur des installations par utilisateur.

Déploiement du pilote WCH CH340

Téléchargez le package officiel CH341SER auprès de JiangSu QinHeng (WCH). L'installateur peut être exécuté silencieusement via la ligne de commande ou PowerShell pendant le déploiement de votre image standard, ou poussé via Intune :

CH341SER.EXE /S

Vous pouvez également extraire les fichiers .inf, .cat et .sys de l'archive et les intégrer à l'aide de l'utilitaire de packages de pilotes Windows (pnputil) :

pnputil.exe /add-driver CH341SER.INF /install

Déploiement du pilote Silicon Labs CP210x

Téléchargez le package CP210x Universal Windows Driver de Silicon Labs. Extrayez l'archive et exécutez pnputil :

pnputil.exe /add-driver silabser.inf /install

Une fois le pilote ajouté au magasin de pilotes Windows via pnputil, n'importe quel élève ouvrant une session sur cet ordinateur peut brancher une carte et obtenir l'attribution d'un port COM actif sans déclencher d'invite de contrôle de compte d'utilisateur (UAC).

4. Autorisations de navigation et API Web Serial

De nombreuses plateformes de programmation modernes (telles que MakeCode, Web Arduino et les éditeurs Python dans le navigateur) reposent sur les API Chromium Web Serial ou WebUSB pour téléverser le firmware directement depuis Google Chrome ou Microsoft Edge. Même lorsque les pilotes sont correctement installés, trois obstacles administratifs peuvent bloquer la communication :

• Blocage des ports série par stratégie de groupe : les administrateurs déploient fréquemment des stratégies d'entreprise sur Chrome/Edge qui désactivent Web Serial. Assurez-vous que la stratégie SerialAllowAllJSDevicesForUrls ou DefaultSerialGuardSetting est configurée pour autoriser les domaines éducatifs à inviter les élèves à sélectionner un port.
• Conflits d'accès aux ports : si une application locale (comme le moniteur série de l'IDE Arduino ou un script Python en arrière-plan) utilise le port COM, le navigateur ne peut pas en réclamer l'accès exclusif. Les élèves doivent fermer les moniteurs série en arrière-plan avant de flasher leur carte depuis un onglet web.
• USB natif vs puces de pont : les microcontrôleurs prenant en charge l'USB natif (comme le Raspberry Pi RP2040, le BBC micro:bit ou les cartes SAMD21) apparaissent comme des périphériques de stockage de masse USB ou WebUSB sans nécessiter de pilotes de pont traditionnels. Si votre salle fonctionne sur des clients légers verrouillés où les pilotes de noyau ne peuvent pas être ajoutés, le matériel USB natif contourne entièrement ce problème.

5. Vérifications matérielles de base : câbles et ports

Si les pilotes sont bien présents et que le périphérique n'apparaît toujours pas dans le Gestionnaire de périphériques, inspectez la liaison physique :

• Câbles micro-USB de charge seule : de nombreux câbles micro-USB bon marché fournis avec des batteries externes ou des périphériques rechargeables ne contiennent que les lignes d'alimentation positive et de masse (VBUS et GND), omettant les lignes de données D+ et D-. Un microcontrôleur connecté avec un câble de charge seule allumera sa LED d'alimentation, laissant penser aux enseignants que la connexion fonctionne, mais il ne sera jamais détecté par le système d'exploitation.
• Chutes de tension sur les concentrateurs en façade : les kits robotiques à forte consommation connectés aux ports USB non alimentés en façade d'ordinateurs fixes peuvent provoquer des baisses de tension sur le microcontrôleur lors de la liaison série. Testez toujours les cartes suspectes directement sur les ports arrière de la carte mère ou sur des hubs USB alimentés.

Si votre établissement configure des chariots d'ordinateurs portables partagés ou prépare le déploiement de matériel d'informatique embarquée sur plusieurs niveaux, notre équipe vous accompagne dans la configuration des réseaux, des pilotes et des salles via Sheen Robotics School Service.