En 2025, imprimer un document devrait être banal… et pourtant c’est souvent l’horreur. Qui ne s’est pas retrouvé un lundi matin devant une imprimante muette, un fichier collé au spooler ou une page sortie moitié vide ? Entre l’écran qui dit « imprimé », les feuilles blanches et le bouton Relancer le spooler, la frustration guette. Tous systèmes confondus – Windows, macOS ou Linux – on constate des bugs récurrents : documents envoyés qui ne sortent jamais, textes déformés, images coupées, couleurs étranges, coupages inopinés… Les causes sont multiples et souvent obscures pour l’utilisateur. Dans certains cas, des applications (Word, PDF, graphisme) dégradent le rendu final ; dans d’autres, des pilotes plantent ou le service d’impression « débloque » mal la tâche. La documentation de Microsoft cite ainsi en exemple des emplois du spooler qui échouent tout simplement si un service Windows n’est pas actif. Sous macOS et Linux, on redémarre souvent à la main la file d’impression (CUPS) qui gère tout le processus. Malgré toutes ces bidouilles, l’utilisateur est la plupart du temps laissé de marbre : la machine fait « feu blanc », et on passe au suivant.
Bugs fréquents. On peut lister plusieurs symptômes typiques (parfois simultanés) :
- Un job « coincé » dans la file d’attente (imprimante affichée comme occupée alors que rien ne sort).
- Des impressions partielles ou tronquées (une feuille s’arrête en plein milieu du texte).
- Des formats altérés ou décalés (colonne index décalée, tableau mal aplati, etc.).
- Des feuilles vierges ou des pages « fantômes » en série.
- Des fonctions avancées (vignettes, recto-verso, couleurs, finitions…) inopérantes ou incorrectes.
Ces cas corrobore l’expérience partagée par les pros qui recommandent de redémarrer le spooler Windows ou le service CUPS sur Linux. Bref, imprimer reste un jeu de patience et de resets…
Pilotes, protocoles et standards hétéroclites
L’une des causes de ce chaos est le manque de standardisation. Historiquement, chaque fabricant a multiplié les langages et drivers propriétaires. Il existe encore des dizaines de langages d’imprimante (PCL, PostScript, ZPL, ESC/P, etc.) et protocoles (IPP, LPD/LPR, SMB/CIFS, AirPrint, IPP-USB…). Autant dire que la pile logicielle est un véritable « mille-feuilles ». Aujourd’hui, une imprimante Wi-Fi moderne est censée parler IPP (Internet Printing Protocol) selon la norme IPP Everywhere, sans pilote dédié. La promesse est belle : « imprimer sur un réseau ou en USB sans logiciel spécifique ». En effet, 98 % des imprimantes récentes supportent IPP/2.0.
Pourtant, la réalité est moins satisfaisante. D’abord, tous les logiciels ne gèrent pas IPP de façon identique. Sous macOS, Apple préfère encore (parfois à tort) le mode AirPrint qui utilise IPP/Bonjour, mais qui ne donne pas accès à toutes les options de l’imprimante. (Résultat : certaines capacités comme la sélection fine du papier ou l’ICC colorimétrique se perdent dans la traduction, et les graphiques en souffrent.) Sous Windows, le « Pilote universel » (Unidrv) a été présenté en 2024, mais il reste un framework à enrichir pour gérer chaque modèle. Microsoft recommande désormais un pilote IPP inbox générique pour Windows 10/11, mais la transition est loin d’être transparente. Sous Linux, on dépend de CUPS et de bibliothèques comme Gutenprint ou Ghostscript, qui ne couvrent pas toujours les toutes dernières imprimantes. Les distributions sont passées au « driverless » (via IPP partout), mais nombre d’utilisateurs confessent devoir tweaker manuellement leurs fichiers PPD ou PCL.
Ce patchwork se traduit par des incompatibilités : un même fichier Word imprimé sous Windows peut donner un résultat différent sous Linux via CUPS. Un document sauvé en PDF sur Mac peut refuser l’impression sur certains serveurs Windows (verrous sécuritaires ou formats non supportés). Chaque système impose ses formats par défaut : Windows favorise le XPS ou les pilotes convertissant en PCL, macOS convertit souvent en PDF ou PS, et Linux cherche le « best guess » driver. En somme, l’impression ressemble à un exercice d’adaptation constant.
Différences entre plateformes
Il y a des raisons pour lesquelles « l’expérience utilisateur » varie selon l’OS. Par exemple, macOS intègre CUPS pour gérer l’impression, et depuis la version 10.7, Apple a purement supprimé le support des protocoles LPD/SMB hérités. En pratique cela veut dire que beaucoup d’anciens serveurs d’impression sous Windows (via SMB) ne fonctionnent plus «out of the box» sur Mac : on est obligé de passer via IPP. C’est un progrès (vers la standardisation) mais cela surprend encore les administrateurs. De son côté, Windows continue de répandre son propre environnement de spooler (et a géré de gros épisodes de vulnérabilités PrintNightmare récemment), ce qui fait redouter des bugs du service d’impression chez les pros IT. Quant à Linux, il bénéficie du moteur CUPS aussi, mais dépend souvent d’un kernel récent et des paquets hplip, cups-filters, etc., qui évoluent plus lentement que le matériel – ce qui se traduit par des imprimantes qui « fonctionnent pas bien » sans driver supplémentaire.
Au final, Windows reste déjà frustrant, avec ses messages d’erreur obscurs et son cantonnement aux pilotes prévus. macOS et Linux peuvent être encore plus limités : l’un privilégie la simplicité (AirPrint autoconfiguration) au prix de fonctionnalités, l’autre suppose un administrateur geek prêt à fouiller les logs CUPS. Dans tous les cas, un professionnel se retrouve souvent à calibrer manuellement chaque impréimante selon le système, et l’utilisateur lambda n’y comprend rien.
Les aléas de l’impression réseau
L’impression en Wi-Fi ou via un réseau local ajoute de nouveaux pièges. Chaque OS utilise souvent un service de découverte différent (Bonjour/mDNS chez Apple, LLMNR/SMB chez Windows, Avahi/CUPS chez Linux). Il suffit qu’un réseau bloque le multicast, ou qu’un firewall DHCP soit mal configuré, pour que l’imprimante disparaissent de la liste. C’est encore plus vrai avec AirPrint sur iPhone/iPad : des mises à jour iOS récentes ont hélas créé des bugs où les imprimantes visibles s’éclipsent subitement. (Sans même parler des protocoles propriétaires des imprimantes professionnelles : AirPrint gère mal par exemple les multifonctions avancées, et Wi-Fi direct ou Bluetooth sont rarement transparents.)
Même en Ethernet, l’utilisation de CUPS impose une configuration fine : par défaut CUPS refuse les travaux en dehors de son sous-réseau, ce qui force à ajouter des commandes comme cupsctl --share-printers --remote-any pour autoriser les impressions distantes. C’est absurde quand on sait que le protocole IPP a été pensé pour le réseau, mais chaque OS reste timoré par rapport à son propre modèle de sécurité. Au bout du compte, un service qui devrait simplement « aller trouver l’imprimante et imprimer » nécessite des contorsions à la fois sur le routeur, la machine hôte et parfois sur l’imprimante elle-même (changement de mode réseau, choix de DNS-SD ou non, etc.).
Une complexité absurde pour un service universel
L’impression est l’un des rares usages informatiques qui devrait être aussi banal que respirer un document, quel que soit le système d’exploitation. Et pourtant, elle reste plombée par un mille-feuille technique. Cette complexité accrue, presque mafieuse tant elle est surnuméraire, contraste avec l’expérience sur smartphone : on clique sur « Imprimer » et en général… ça marche (quand ce n’est pas un café qui sort à la place). Les professionnels l’admettent : si on a un pilote omniprésent comme IPP Everywhere, il faudrait une vraie volonté industrielle de l’imposer dans tous les OS et logiciels. Or l’héritage Windows, les écosystèmes fermés (Apple oblige, tous ses OS tenant d’unifier via AirPrint) et la dispersion des drivers font qu’on nage encore dans le « Chaque éditeur sa solution ».
Il est peut-être temps de sortir de ce carcan. La situation n’a que trop duré : lors de la prochaine révision des systèmes, pourquoi ne pas rendre l’impression vraiment plug-and-play universel ? Imaginer un état où envoyer un fichier sur n’importe quelle imprimante reliée au réseau produit toujours le bon résultat, sans mise à jour de pilote ni bidouille IP locale. Cette idée n’est pas de la science-fiction : la base en existe (norme IPP, PDF comme format d’échange, etc.), il faut juste une concertation fournisseur-système pour la pousser à fond.
En attendant, imprimer reste un sujet digne d’un sketch de bureau : bien au chaud dans les conférences IT, on salue les informaticiens capables de sortir d’une grappe de serveurs CUPS un service qui tient sans crash. Il est grand temps de souligner l’absurdité de tout ça et de réclamer une refonte simplifiée – ou au moins un standard vraiment commun. Car, en 2025, personne ne devrait encore résoudre des imprimantes en 13 étapes en regardant les diodes clignoter.