En 2010, quand j’ai commencé à documenter CMSimple_XH, Android n’existait déjà plus tout à fait dans sa forme initiale — mais c’est un tout autre système que je veux évoquer ici, pour une raison précise : j’ai retrouvé l’an dernier deux tablettes fonctionnant encore sous Android 3.0 Honeycomb chez un client, et ce cas mérite d’être documenté.
Ce qu’était Honeycomb
Honeycomb, sorti en février 2011, était la première version d’Android pensée spécifiquement pour les tablettes plutôt qu’adaptée d’un système téléphone. Elle a introduit l’interface holographique, la barre système persistante et la navigation par fragments — des concepts qui ont ensuite irrigué les versions suivantes d’Android. Elle n’a jamais été portée aux téléphones et a rapidement été remplacée par Ice Cream Sandwich, qui a unifié les deux lignes.
Contrairement à ce qu’on pourrait penser, ce n’est pas un système qu’on retrouve par nostalgie. C’est un système qu’on retrouve parce que le matériel qui le faisait tourner — des tablettes premier prix achetées en lot par des PME entre 2011 et 2012 pour des usages internes simples — a tout simplement continué à fonctionner physiquement, sans jamais recevoir de mise à jour, et sans que personne ne pense à s’en débarrasser tant qu’elles « marchaient encore ».
Le cas rencontré
Ces deux tablettes servaient à afficher un planning en salle d’accueil, connecté au Wi-Fi local. Le problème est apparu quand le point d’accès Wi-Fi a été remplacé : le nouveau matériel n’acceptait plus certains protocoles de sécurité obsolètes (WEP et versions anciennes de WPA) que Honeycomb pouvait gérer, et les tablettes se sont retrouvées incapables de se reconnecter.
Une fois les vrais goulots d’étranglement identifiés — pas les supposés — la solution n’était pas de réparer les tablettes mais de les retirer du réseau. Un navigateur de 2011 exposé à internet en 2026, même pour un usage interne apparemment anodin, représente une surface d’attaque qu’aucune rustine ne compense : plus aucune mise à jour de sécurité n’a été publiée pour ce système depuis plus d’une décennie.
La leçon sur la dette technique matérielle
On parle beaucoup de dette technique logicielle — code non maintenu, dépendances obsolètes. La dette technique matérielle est moins documentée mais tout aussi réelle : un appareil qui continue à fonctionner physiquement finit par être oublié dans l’inventaire, alors que son système d’exploitation est mort depuis des années. Ce n’est pas une affirmation abstraite ; c’est ce que j’ai vu directement sur ce cas et sur au moins deux autres, à des échelles différentes, au cours des dernières années.
Mise en garde essentielle : tout appareil connecté au réseau, même pour un usage jugé secondaire, doit figurer dans un inventaire à jour avec sa date de fin de support. Sans cet inventaire, ces appareils ne réapparaissent qu’au moment d’un incident.
Ce qu’on retrouve encore aujourd’hui
Ce cas n’est pas isolé. J’ai également documenté, chez une autre structure, un lecteur de badges fonctionnant sous Windows CE — un système encore plus ancien que Honeycomb — relié au réseau interne pour la remontée des pointages. La logique est identique : le matériel physique survit largement à son système d’exploitation, et personne ne remet en question un équipement qui « fait son travail », jusqu’à ce qu’un changement d’infrastructure environnante révèle brutalement son obsolescence.
Comment documenter ce type de matériel
Pour un inventaire utile, je recommande de noter, pour chaque appareil connecté : le système d’exploitation exact et sa version, la date de fin de support officielle du fabricant, la fonction précise de l’appareil, et surtout — le point le plus souvent oublié — ce qui casserait concrètement si l’appareil était retiré du réseau demain. Cette dernière question permet de distinguer un appareil réellement indispensable d’un appareil simplement toléré par habitude.
Une fois cet inventaire fait, le remplacement peut être planifié plutôt que subi. Sur le cas des tablettes Honeycomb, la solution finale a été un remplacement par des écrans d’affichage dynamique classiques, sans système d’exploitation généraliste exposé au réseau — une architecture plus simple et surtout sans surface d’attaque comparable.
À retenir pour votre projet
Si vous gérez l’infrastructure d’une petite structure, faites l’inventaire physique une fois par an, pas seulement l’inventaire logiciel. Les appareils « qui marchent encore » sont précisément ceux qu’on oublie de questionner.
Recycler plutôt que jeter
Une dernière remarque sur ce cas précis : les deux tablettes retirées n’ont pas fini à la déchetterie immédiatement. Une fois réinitialisées et déconnectées définitivement de tout réseau, elles ont trouvé un usage résiduel comme cadres photo numériques en salle de pause — un usage totalement hors ligne, où l’obsolescence du système d’exploitation ne représente plus aucun risque puisqu’aucune connexion n’est requise. Ce n’est pas une solution généralisable à tout matériel obsolète, mais ça illustre qu’un retrait du réseau ne signifie pas nécessairement une mise au rebut complète.
Le rôle du réseau dans le diagnostic
Ce cas illustre aussi un principe que j’applique à chaque diagnostic réseau, quel que soit l’appareil concerné : le symptôme visible (impossibilité de se connecter) n’est presque jamais la cause réelle. Ici, le symptôme était la déconnexion Wi-Fi ; la cause réelle était l’obsolescence du protocole de sécurité supporté par le système d’exploitation. Un diagnostic qui s’arrête au symptôme mène à des correctifs superficiels — redémarrer la tablette, réinitialiser la configuration réseau — qui ne résolvent rien durablement, puisque le protocole reste incompatible quelle que soit la tentative de reconnexion.
Une nuance sur le remplacement systématique
Reconnaissons une limite à cette recommandation : tout appareil ancien ne mérite pas un remplacement immédiat. Un appareil non connecté au réseau, utilisé en autonomie complète pour une fonction isolée, présente un risque très différent d’un appareil connecté exposé à des protocoles réseau modernes. La question à se poser n’est donc pas seulement « cet appareil est-il ancien », mais « cet appareil communique-t-il avec autre chose, et si oui, ce canal de communication peut-il être exploité ». Cette distinction évite des remplacements coûteux et inutiles sur du matériel isolé, tout en priorisant correctement les appareils réellement exposés.
Pour aller plus loin
Pour une référence externe, consultez la documentation officielle d’Android ainsi que l’historique des versions d’Android.