Introduction : Le Monde invisible d’AutoCAD®
AutoCAD® est depuis des décennies la pierre angulaire de la conception et de l’ingénierie, évoluant d’un logiciel de dessin 2D rudimentaire sur micro-ordinateurs à une puissante plateforme de modélisation 3D sophistiquée. Son adoption généralisée dans les secteurs de l’architecture, de l’ingénierie et de la construction (AIC) a consolidé sa position de norme industrielle. Cependant, malgré son omniprésence, de nombreux utilisateurs, même les professionnels expérimentés, ne font souvent qu’effleurer ses capacités, se fiant aux commandes et fonctionnalités les plus courantes. Ce rapport vise à lever le voile, révélant les facettes moins connues qui font d’AutoCAD® un logiciel véritablement fascinant – un monde de commandes cachées, de curiosités historiques et de secrets de développeurs ludiques qui s’étendent bien au-delà de la documentation publique.
Ce document propose un voyage captivant dans l’histoire méconnue du logiciel, ses commandes secrètes, ses particularités ludiques et ses puissantes fonctionnalités cachées. Il explore les récits fascinants de sa création, en examinant les défis initiaux et les décisions visionnaires qui l’ont façonné. Le rapport dévoile des commandes et des variables système qui demeurent non documentées, offrant un aperçu du fonctionnement interne du logiciel et de ses fonctionnalités surprenantes. Il examine également les « Easter eggs » (œufs de Pâques) ludiques dissimulés par les développeurs et les « farces » créatives imaginées par les utilisateurs. Enfin, il met en lumière des fonctionnalités avancées qui, bien que parfois négligées, peuvent révolutionner le flux de travail d’un utilisateur averti. L’objectif n’est pas seulement de présenter des faits obscurs, mais de comprendre l’ADN profond d’un programme qui continue de façonner des industries à travers le monde.
Chapitre 1 : Les années de formation d’AutoCAD® : anecdotes des débuts du dessin numérique
1.1 Des tables à dessin aux écrans numériques : les défis des ingénieurs avant la CAO et la révolution d’AutoCAD®
Avant l’avènement des systèmes de conception assistée par ordinateur (CAO), le monde du design dans les années 1950 était dépourvu d’ordinateurs, de connexions Wi-Fi et d’Internet. Les ingénieurs chargés de concevoir un nouveau bâtiment de bureaux s’appuyaient entièrement sur le papier et le crayon, travaillant sur d’immenses tables à dessin avec des outils physiques. Ces « pages » pouvaient être aussi grandes que les sols sur lesquels ils marchaient, un contraste frappant avec les formats numériques standardisés d’aujourd’hui. Cette approche manuelle, bien que témoignant d’une ingéniosité et d’un savoir-faire remarquables, était entravée par de nombreuses limitations.
L’un des défis les plus redoutables était l’absence d’une fonction « annuler ». Corriger des erreurs ou modifier des parties d’un dessin nécessitait des heures de corrections manuelles méticuleuses, exigeant souvent de redessiner des éléments entiers. Ce processus exigeait une attention extrême aux détails et une persévérance considérable, chaque révision étant une entreprise significative. La collaboration était limitée au partage physique des dessins, et le stockage impliquait de vastes archives physiques sujettes à la perte ou aux dommages. L’incapacité de revenir facilement sur les modifications limitait fondamentalement l’itération de la conception et la prise de risques. Si chaque erreur ou changement impliquait des heures de travail, les concepteurs seraient naturellement plus conservateurs, moins expérimentaux et moins disposés à explorer de multiples alternatives.
La première avancée significative survint en 1963 avec Sketchpad d’Ivan Sutherland, un programme de CAO graphiquement interfacé, bien que rudimentaire selon les normes actuelles. Cela jeta les bases des systèmes de CAO modernes. AutoCAD®, s’inscrivant dans cette lignée, offrit une efficacité et une précision inégalées. Son introduction de fonctionnalités telles que les blocs dynamiques signifiait que les ingénieurs n’avaient plus à redessiner manuellement chaque élément pour les variations, un bond monumental par rapport aux années 1950 sans fonctions de copier-coller. La transition des méthodes traditionnelles vers AutoCAD® a représenté un profond changement de paradigme, transformant la conception d’un artisanat manuel laborieux en un processus numérique dynamique. La fonction « annuler », apparemment simple, fut un puissant catalyseur des méthodologies de conception itératives, qui sont aujourd’hui une pierre angulaire de l’ingénierie et de l’architecture modernes.
1.2 Les pionniers derrière la souris : histoires de la fondation d’Autodesk®, du logiciel initial « Interact », de ses changements de nom et des visionnaires des premiers jours
L’entreprise connue aujourd’hui sous le nom d’Autodesk® a été fondée le 30 janvier 1982, à Mill Valley, en Californie. Ce fut un effort collaboratif de 16 programmeurs, dont John Walker et Daniel Drake, qui ont mis en commun la modeste somme de 60 000 dollars pour financer le démarrage. Initialement, l’entreprise était une collaboration informelle centrée sur les programmeurs, nommée Marin Software Partners.
Le programme central qui allait devenir AutoCAD® a été initialement développé par Mike Riddle, qui a commencé à travailler sur un programme graphique qu’il a appelé « Interact » en 1977. Riddle, consultant informatique indépendant, avait déjà été exposé à la CAO grâce à un système Computervision de 250 000 dollars utilisé pour le dessin 2D chez un fabricant d’acier. Il était convaincu qu’un travail similaire pouvait être réalisé sur des micro-ordinateurs. Il a eu du mal à vendre « Interact » mais a finalement accepté de le céder à John Walker en échange de redevances.
« Interact » a subi un changement de nom pour devenir « microCAD », mais ce nom était déjà utilisé par une autre entreprise, ce qui a conduit à son nom final et emblématique : « AutoCAD® ».
Les cofondateurs étaient initialement incertains de leur orientation technologique, prévoyant jusqu’à cinq applications logicielles différentes pour voir laquelle réussirait. John Walker lui-même considérait initialement la CAO comme un « domaine de niche », comparant le nombre d’architectes à celui des personnes qui écrivent des documents. Cependant, la forte réaction du public à AutoCAD® lors de ses débuts au Comdex de Las Vegas en 1982, associée au désintérêt pour leur autre produit (un éditeur de texte), a résolument orienté l’entreprise. AutoCAD® a été mis en vente en décembre 1982 et a généré un chiffre d’affaires impressionnant de 1,4 million de dollars au cours de sa première année. Ce succès précoce a validé leur réorientation et a tracé la voie de l’avenir d’Autodesk®. Cette séquence d’événements illustre comment le retour d’information précoce du marché et la réception des utilisateurs peuvent fondamentalement rediriger la stratégie d’une entreprise. Malgré le scepticisme interne quant à la taille du marché de la CAO, la réponse positive écrasante des utilisateurs potentiels au Comdex a servi de signal indéniable. Ce moment charnière démontre que la demande des utilisateurs, même à ses débuts, peut être une force plus puissante pour façonner le développement de produits et la stratégie commerciale que les projections internes initiales ou les préjugés des fondateurs.
1.3 Obstacles initiaux et impacts imprévus : le célèbre AutoCAD® R13, la controverse du verrou matériel et l’évolution des fonctionnalités à partir des besoins des utilisateurs
AutoCAD® 2.5, lancé en juin 1986, a marqué une première significative, bien que controversée : ce fut la première version aux États-Unis et au Canada à exiger un verrou matériel pour la protection contre la copie. Cette décision, visant à freiner le piratage, a suscité de nombreuses plaintes d’utilisateurs. Autodesk®, à l’écoute de sa base d’utilisateurs, a rapidement publié AutoCAD® 2.5, qui a supprimé ce verrou matériel. Cet incident souligne l’influence précoce des retours d’utilisateurs sur la politique produit et les défis liés à l’équilibre entre les besoins commerciaux et l’expérience utilisateur.
AutoCAD® R13, introduit en novembre 1994, occupe une place notoire dans l’histoire du logiciel. Il a été largement considéré comme la « version la plus détestée » lors de ses débuts, étant « tellement boguée ». L’entreprise a été contrainte de livrer rapidement une série de mises à jour incrémentielles pour résoudre les nombreux problèmes. Cette période a représenté un test significatif pour la réputation d’Autodesk® et sa capacité à répondre aux problèmes critiques des utilisateurs, démontrant la nature itérative et parfois douloureuse du développement logiciel.
Au-delà des controverses, le développement d’AutoCAD® a connu une évolution continue. AutoCAD® Release 9 était affectueusement surnommé « The White Album ». Une étape visuelle et fonctionnelle majeure est arrivée avec AutoCAD® 2009, qui a introduit l’interface ruban, l’InfoCenter, les Propriétés Rapides, le ViewCube, les Steering Wheels et l’Action Recorder. Ces changements reflètent un effort continu pour moderniser l’expérience utilisateur et améliorer la productivité.
Les incidents du verrouillage matériel et des problèmes de la version R13 mettent en évidence que le développement logiciel, en particulier pour un produit largement utilisé comme AutoCAD®, est un processus continu et itératif fortement influencé par la base d’utilisateurs. L’incident du verrouillage matériel montre que même des décisions commerciales bien intentionnées peuvent être annulées en raison d’une expérience utilisateur négative, démontrant le pouvoir du retour d’information collectif des utilisateurs. La débâcle de la R13 illustre que même avec un développement rigoureux, les versions majeures peuvent présenter des problèmes de qualité importants, et les mises à jour rapides qui ont suivi soulignent que les bogues signalés par les utilisateurs deviennent des moteurs essentiels pour l’amélioration immédiate du produit. Cette dynamique implique que la communauté d’utilisateurs fonctionne comme un mécanisme d’assurance qualité et de définition des politiques essentiel et réel, poussant le logiciel vers une plus grande convivialité et stabilité grâce à leur engagement et à leurs commentaires directs.
Chapitre 2 : Les murmures de la ligne de commande : commandes et variables système non documentées
2.1 Dévoiler l’obscur : commandes introuvables dans les fichiers d’aide
La ligne de commande d’AutoCAD®, une interface directe avec le cœur du logiciel, recèle souvent des secrets qui ne sont pas explicitement répertoriés dans la documentation officielle. Ces commandes non documentées peuvent être des vestiges du développement passé, des outils de test internes ou des fonctionnalités de niche qui n’ont jamais été intégrées à l’interface utilisateur principale. Les explorer offre un aperçu unique des couches historiques d’AutoCAD® et des intentions des développeurs.
*SCROLL
(R12) : Cette commande réinitialise les barres de défilement de « panoramique ».5 Bien que cela puisse paraître mineur, il peut s’agir d’une solution rapide utile pour les problèmes d’affichage liés à la navigation..ACADSTATUS
(avant R12) /.ACLTSTATUS
(R13) : Ces commandes créent un fichier journal d’état interne (ACAD.SLG
) dans le répertoire de l’exécutable AutoCAD®.5 Elles nécessitent un préfixe de point supplémentaire (.
) pour être utilisées sur la ligne de commande, une convention courante pour les commandes internes ou « cachées ». Ce sont des exemples clairs d’utilitaires de développeur, probablement pour le débogage ou la surveillance des performances.CONVERTPOLY
(R14) : Il s’agit d’une commande non documentée particulièrement précieuse qui convertit dans les deux sens entre les polylignes de l’ancien style et les nouvelles polylignes légères.5 La recherche la qualifie de « très utile », soulignant son utilité pratique pour la gestion des données de dessin et la compatibilité, en particulier dans les environnements anciens ou à versions mixtes.-OLDMTEXT
/OLDMTEXT
(R14) : Ces commandes exécutent la commande MTEXT de la version R13.5 Cela suggère une décision consciente d’Autodesk® de fournir une option de repli vers une version plus ancienne de l’éditeur de texte multiligne, peut-être en raison des préférences des utilisateurs ou pour atténuer les problèmes avec la version R14. C’est un clin d’œil subtil à la compatibilité ascendante et au choix de l’utilisateur.ENDSV
(R12) : Une variante intrigante de la commandeEND
, elle inclut un avertissement concernant l’impossibilité d’enregistrer les fichiers vectoriels.5 Cela fait allusion à une gestion interne spécifique des fichiers ou à des capacités de sortie vectorielle héritées qui auraient pu faire partie d’un développement antérieur.FILEOPEN
(R12) : Une variante de la commandeOPEN
utilisable uniquement en ligne de commande, cette commande est émise en interne lors de la sélection d’un fichier dans la liste des fichiers récemment utilisés (MRU) du menu ‹ Fichier ›.5 Elle révèle la structure de commande sous-jacente aux actions courantes de l’interface utilisateur.KABOOM!
(R13) : Cette commande « ne fait rien » mais est décrite comme « amusante ».5 C’est une commande ludique et non fonctionnelle, un petit « Easter egg » de développeur ou une blague interne.KRISTI
(R13) : Cette commande crée des fichiers de définition de ressources pour les boutons de barre d’outils (cat_acad.h
,cat_acad.rc
).5 Il s’agit probablement d’un outil interne utilisé par une développeuse nommée Kristi pour gérer les éléments de l’interface utilisateur.PAINTER
(R13/R14) : Cette commande ne fait rien dans R13 mais exécute_MATCHPROP
dans R14.5 Cela montre une commande réaffectée ou activée dans des versions ultérieures, reflétant des fonctionnalités en évolution ou une refactorisation de code interne.PRPLOT
(avant R12) /AXIS
(avant R12) : Ces deux commandes sont explicitement notées comme étant abandonnées.5 Leur présence dans la table des commandes, même si elles sont désactivées, sert de trace archéologique des fonctionnalités qui ont été supprimées ou remplacées au cours de la longue histoire d’AutoCAD®.ACRX_RESIDENT_COMMAND__DEFINE_MAX_BUFFER_SIZE_AS_64_CHARS_MAX_XX
(R13) : Cette commande est particulièrement remarquable car elle est documentée pour provoquer le plantage d’AutoCAD® R13.5 C’est un exemple fascinant d’une commande qui, lorsqu’elle est déclenchée, provoque une instabilité – probablement un artefact de débogage ou une commande de test qui n’a jamais été complètement supprimée.OOPS
: Cette « fonctionnalité oubliée » restaure le dernier objet supprimé, quelles que soient les autres opérations effectuées entre-temps.6 Contrairement àUNDO
, qui annule la dernière action,OOPS
cible spécifiquement la dernière entité supprimée, ce qui en fait un puissant outil de récupération pour les suppressions accidentelles.
La ligne de commande, dans ce contexte, fonctionne comme un site archéologique vivant. Ce n’est pas seulement une interface utilisateur ; c’est une fenêtre directe et non filtrée sur l’évolution du code, les processus de test internes, les particularités des développeurs et les défis liés au maintien de la compatibilité ascendante ou à l’obsolescence des fonctionnalités au fil des décennies. L’existence de ces commandes implique que le fonctionnement interne d’AutoCAD® est stratifié, avec des artefacts historiques persistant sous la surface. Pour un utilisateur curieux, cela offre une perspective unique sur le parcours du logiciel, révélant l’élément humain et les décisions d’ingénierie qui ont jalonné son évolution.
Tableau 1 : Commandes AutoCAD® non documentées
Commande | Version Introduite | Notes/Description | Utilisation Pratique (si applicable) |
---|---|---|---|
*SCROLL |
R12 | Réinitialise les barres de défilement de « panoramique ». | Correction rapide des problèmes d’affichage de navigation. |
.ACADSTATUS |
avant R12 | Crée un fichier journal d’état interne (ACAD.SLG ). |
Outil de débogage/surveillance des performances. |
.ACLTSTATUS |
R13 | Idem que .ACADSTATUS pour AutoCAD LT®. |
Outil de débogage/surveillance des performances. |
.SYSSTATUS |
R14 | Ne fait rien. | Vestige de développement. |
-OLDMTEXT |
R14 | Exécute la commande MTEXT de la version R13. | Option de compatibilité pour l’éditeur de texte. |
ADIDUMP |
R13 | Ne fait rien. | Vestige de développement. |
AXIS |
avant R12 | Indique que c’est une commande abandonnée. | Trace historique. |
CONTENT |
R14 | Ne fait rien. | Vestige de développement (peut-être un prélude à ‹ Content Explorer ›). |
CONVERTPOLY |
R14 | Convertit les polylignes anciennes en polylignes légères et vice-versa. | Très utile pour la gestion des données et la compatibilité. |
DLGCOLOR* |
R13 | Contrôle les couleurs de dialogue dans R13/DOS. | Fonctionnalité spécifique à une version/OS. |
DRGINSERT |
R14 | Ne fait rien. | Vestige de développement. |
DUMPMEMALLOC |
R13 | Fournit des informations internes sur la mémoire. | Outil de débogage/diagnostic. |
DVBIN |
R14 | Ne fait rien. | Probablement pour l’importation de macros VBA. |
DVBOUT |
R14 | Ne fait rien. | Probablement pour l’exportation de macros VBA. |
ENDSV |
R12 | Variante de END avec avertissement sur l’enregistrement des fichiers vectoriels. |
Indique une gestion interne spécifique des fichiers. |
FILEOPEN |
R12 | Variante de OPEN en ligne de commande. |
Révèle la structure de commande sous-jacente. |
KABOOM! |
R13 | Ne fait rien. | Blague de développeur/Easter egg. |
KRISTI |
R13 | Crée des fichiers de définition de ressources pour les boutons de barre d’outils. | Outil de développeur interne. |
MAKEBLK |
R14 | Ne fait rien. | Vestige de développement. |
OFFLINE |
R13 | Avertit « not converted to AcDb yet », puis ne fait rien. | Vestige de développement. |
OLDMTEXT |
R14 | Exécute la commande MTEXT de la version R13. | Option de compatibilité pour l’éditeur de texte. |
OLDMTPROP |
R14 | Exécute la commande MTPROP de la version R13. | Option de compatibilité. |
PAINTER |
R13 | Ne fait rien dans R13, exécute _MATCHPROP dans R14. |
Commande réaffectée/activée dans des versions ultérieures. |
PRPLOT |
avant R12 | Indique que c’est une commande abandonnée. | Trace historique. |
RENDENV |
R14 | Ne fait rien. | Vestige de développement. |
SETENV |
R13 | Ne fait rien. | Vestige de développement. |
UNLOCK |
R13 | Ne fait rien. | Vestige de développement. |
VIEWTOOLBAR |
R13 | Ne fait rien. | Vestige de développement. |
XDRGINSERT |
R14 | Ne fait rien. | Vestige de développement. |
OOPS |
- | Restaure le dernier objet supprimé. | Outil de récupération puissant pour les suppressions accidentelles. |
ACRX_RESIDENT_COMMAND__DEFINE_MAX_BUFFER_SIZE_AS_64_CHARS_MAX_XX |
R13 | Provoque le plantage d’AutoCAD® R13. | Artefact de débogage/test (à éviter). |
2.2 Regarder derrière le rideau : Variables Système cachées
Les variables système contrôlent divers paramètres et comportements d’AutoCAD®, des options d’affichage aux paramètres de performance. Beaucoup d’entre elles sont documentées, mais quelques-unes restent cachées, offrant un contrôle plus approfondi ou révélant des données internes que les utilisateurs expérimentés pourraient trouver inestimables.
_LINFO
(avant R12) : Cette variable renvoie le numéro de série du verrou matériel.7 C’est un lien direct avec le système de protection contre la copie qui a provoqué une controverse dans les versions antérieures, un artefact historique au cœur du logiciel._PKSER
(R9) : Affiche le numéro de série d’AutoCAD® (lecture seule).7 Une note historique fascinante est que dans les versions antérieures à R11, cette chaîne de numéro de série pouvait être « piratée ». Cependant, dans R11, un « crochet dans la commande ZOOM a été activé pour faire planter immédiatement AutoCAD® si la chaîne du numéro de série était altérée ».7 C’est une anecdote de premier ordre sur les mesures anti-piratage précoces et agressives intégrées directement dans les fonctionnalités de base._SERVER
(R11) : Indique l’état du serveur de licence réseau (lecture seule).7 Utile pour les diagnostics dans les environnements en réseau._VERNUM
(R13) : Affiche le numéro de build précis d’AutoCAD®.7 Essentiel pour le support technique ou l’identification précise de la version.ENTEXTS
(R12) : Cette variable contrôle le calcul des étendues de dessin, avec des valeurs (0, 1 ou 2) offrant différents compromis entre les performances et l’utilisation de la mémoire.7 La définir à 2, par exemple, met en cache les étendues sous forme de valeurs longues pour les calculs les plus rapides, bien qu’elle utilise plus de mémoire. C’est une variable pratique pour optimiser les performances dans les dessins volumineux et complexes.ENTMODS
(R12) : S’incrémente chaque fois qu’un objet de base de données est modifié (lecture seule).7 Cette variable de diagnostic fournit un compteur interne pour suivre les modifications au sein d’un dessin.GLOBCHECK
(R13) : Cette variable, lorsqu’elle est définie à 3, affiche la taille des boîtes de dialogue DCL lors de l’affichage d’une boîte de dialogue. Plus important encore, lorsqu’elle est définie à >0, elle peut interdire les commandes en langue locale.7 Cette dernière est notée comme « très utile pour les développeurs », indiquant son rôle dans le débogage ou l’application des normes de développement, en particulier dans un environnement logiciel mondialisé.JWDEBUG
(R9-R10) /KESDEBUG
(R9) : Il s’agit probablement de drapeaux de « débogage » utilisés par des programmeurs spécifiques avec les initiales J.W. (peut-être John Walker) et K.E.S..7 Leur présence est une empreinte directe des développeurs laissée dans le code, un clin d’œil subtil à l’élément humain derrière le logiciel.NOMUTT
(R14.01) : Lorsqu’elle est définie à 1 (Vrai), aucune invite de saisie n’est affichée dans la ligne de commande.7 Cela peut être utile pour le scriptage avancé où les invites sont gérées par programme, ou, comme cela sera vu, pour des farces ludiques.8QAFLAGS
(R11) : Il s’agit d’une puissante variable de code binaire contrôlant divers comportements. Par exemple, le bit 0 (valeur 1) fait que^C
dans une macro de menu annule les poignées (agissant comme la touche<Esc>
du clavier). Le bit 1 (valeur 2) supprime les pauses pendant les listes d’écran de texte, et le bit 2 (valeur 4) supprime les boîtes de dialogue « alerte », affichant du texte à la place.7 Cette variable permet aux utilisateurs avancés ou aux scripteurs d’affiner le comportement interactif d’AutoCAD®, potentiellement en contournant les confirmations utilisateur par défaut pour des flux de travail plus rapides.HIDETEXT
(Variable système) : Bien que désormais documentée, sa fonction spécifique est souvent négligée. Elle spécifie si les objets texte créés par les commandesTEXT
ouMTEXT
sont traités (c’est-à-dire cachés) lors d’une commandeHIDE
.9 Cela permet des présentations visuelles plus propres des modèles 3D sans avoir à basculer manuellement les calques de texte.OBJECTISOLATIONMODE
(Variable système) : Cette variable système cruciale contrôle si les objets cachés ou isolés persistent entre les sessions de dessin.10 La définir à 1 garantit que les objets cachés à l’aide des commandesISOLATEOBJECTS
ouHIDEOBJECTS
restent cachés après l’enregistrement et la réouverture du dessin, ce qui représente un gain de temps significatif pour la gestion des états d’affichage temporaires dans les dessins complexes.
La présence de variables système conçues pour le diagnostic interne, la protection contre le piratage, et le débogage spécifique aux développeurs, aux côtés d’autres variables moins connues qui offrent aux utilisateurs un contrôle granulaire sur les performances, le comportement de l’interface utilisateur et même la suppression des invites, révèle une tension fascinante. Cette tension existe entre l’intention originale des développeurs pour ces variables (contrôle interne, débogage, protection) et la découverte et la réaffectation de celles-ci par les utilisateurs avancés pour une personnalisation et une efficacité accrues. Le fait que ces mécanismes internes soient accessibles, même s’ils ne sont pas documentés, permet aux utilisateurs de modifier le comportement du logiciel de manière non explicitement prévue. Cela suggère que la nature « cachée » de ces variables ne concerne pas toujours le secret, mais parfois la fourniture d’une couche de contrôle plus profonde et plus technique que seule une partie de la base d’utilisateurs recherchera et exploitera, estompant les frontières entre une application fixe et une plateforme personnalisable.
Tableau 2 : Variables Système AutoCAD® non documentées
Variable | Type | Plage | Version Introduite | Notes/Description | Utilisation Pratique/Implication |
---|---|---|---|---|---|
_LINFO |
string | - | avant R12 | Numéro de série du verrou matériel. | Diagnostic de licence, trace historique de la protection. |
_PKSER |
string | - | R9 | Numéro de série AutoCAD® (lecture seule). | Identification de la version, historique des mesures anti-piratage (plantage via ZOOM si altéré dans R11). |
_SERVER |
boolean | 0/1 | R11 | État du serveur de licence réseau (lecture seule). | Diagnostic de licence réseau. |
_VERNUM |
string | - | R13 | Numéro de build AutoCAD®. | Identification précise de la version pour le support. |
AUXSTAT |
integer | -32768 - 32767 | R13 | État du périphérique d’entrée auxiliaire. | Diagnostic des périphériques. |
AXISMODE |
boolean | 0/1 | avant R12 | Vestige de l’ancienne commande AXIS, non utilisé. | Trace historique. |
AXISUNIT |
'(x y) | - | avant R12 | Vestige de l’ancienne commande AXIS, non utilisé. | Trace historique. |
BS_BITS |
integer | -32768 - 32767 | R11 seulement | Fonction inconnue. | Artefact de développement. |
DBGLISTALL |
* | * | R10 | Fonction inconnue (était entier, puis booléen). | Artefact de débogage. |
ENTEXTS |
integer | R12 | Contrôle le calcul des étendues de dessin (0: lent/moins mémoire, 1: compromis, 2: rapide/plus mémoire). | Optimisation des performances pour les grands dessins. | |
ENTMODS |
integer | 0 - ~4Gig | R12 | S’incrémente à chaque modification d’objet de base de données (lecture seule). | Diagnostic pour le suivi des modifications. |
FORCE_PAGING |
integer | 0 - ~4Gig | R13 | Fonction inconnue. | Artefact de développement. |
GLOBCHECK |
integer | R13 | 3 : affiche la taille des dialogues DCL. >0 : désactive les commandes en langue locale. |
Utile pour les développeurs (débogage, normes). | |
JWDEBUG |
? | ? | R9 - R10 | Drapeau de débogage (peut-être John Walker). | Empreinte de développeur. |
KESDEBUG |
? | ? | R9 seulement | Drapeau de débogage (peut-être K.E.S.). | Empreinte de développeur. |
LAZYLOAD |
boolean | 0/1 | R13 | Fonction inconnue. | Artefact de développement. |
NODENAME |
string | - | R13 | Nom du nœud AutoCAD®. | Identification du système. |
NOMUTT |
boolean | 0/1 | R14.01 | 1 (Vrai): Aucune invite de saisie affichée. |
Scripting avancé, farces. |
PHANDLE |
integer | 0 - ~4Gig | R12 | Fonction inconnue. | Artefact de développement. |
PRODUCT |
string | - | R14 | Nom du produit (ex: « AutoCAD® ») (lecture seule). | Identification du produit. |
PROGRAM |
string | - | R14 | Nom de l’exécutable (ex: « ACAD™ ») (lecture seule). | Identification du programme. |
QAFLAGS |
bitcode | 0 - 32767* | R11 | Contrôle divers comportements (ex: ^C annule les poignées, pas de pause dans les listes, pas de dialogues d’alerte). |
Personnalisation avancée du comportement interactif. |
HIDETEXT |
Switch | 0/1 | - | Spécifie si le texte est traité lors d’une commande HIDE. | Améliore la visualisation des modèles 3D. |
OBJECTISOLATIONMODE |
Integer | 0/1 | - | Contrôle si les objets cachés/isolés persistent entre les sessions. | Gain de temps pour la gestion de l’affichage temporaire. |
Chapitre 3 : Code Ludique : Easter Eggs, Farces et Clins d’Œil des Développeurs
3.1 La chasse aux Easter Eggs : faits, fictions et poissons d’avril
Le concept d’« Easter eggs » — messages, fonctionnalités ou jeux cachés — est une tradition appréciée dans le développement logiciel. AutoCAD®, malgré son objectif d’ingénierie sérieux, a fait l’objet de plusieurs rumeurs et de véritables Easter eggs, estompant souvent la frontière avec les farces communautaires et l’humour des développeurs.
L’un des « Easter eggs » les plus élaborés et les plus discutés a été détaillé dans un article de blog par Fenton Webb, ingénieur chez Autodesk®. Il affirmait qu’AutoCAD® 2014 contenait une « version d’émulation complète de Call of Duty Modern Warfare 3 », accessible via une séquence alambiquée de frappes de clavier et de mouvements de souris. Webb a même suggéré de manière sensationnelle qu’il pouvait se connecter au réseau PS3. Cependant, la date de l’article de blog — le 1er avril 2013 — révèle qu’il s’agissait d’une blague du poisson d’avril très créative et réussie. Cela met en évidence le côté ludique de la communauté des développeurs et l’empressement des utilisateurs à croire aux trésors cachés.
Une autre blague du poisson d’avril, celle-ci affirmait qu’une version alternative de PACMAN appelée « CAD-PAC » pouvait être activée par une séquence spécifique de commandes. Bien que l’idée ait été amusante et ait trouvé un écho auprès des utilisateurs, il s’agissait d’un canular, servant de rappel pour vérifier de telles affirmations.
Bien qu’il ne s’agisse pas d’un « Easter egg » intégré par Autodesk® lui-même, le plugin Sokoban est un véritable exemple d’ajout ludique disponible via l’Autodesk® App Store. Ce plugin gratuit permet aux utilisateurs de jouer au jeu de puzzle de transport classique à l’intérieur d’AutoCAD®, offrant un moyen unique de se détendre pendant les pauses. Ce qui le rend particulièrement intéressant, c’est que les utilisateurs peuvent même créer leurs propres niveaux en utilisant des commandes AutoCAD® courantes, démontrant comment la communauté elle-même contribue à l’aspect « amusement caché » de l’écosystème logiciel.
La prévalence de ces histoires d’« Easter eggs », qu’elles soient réelles ou fausses, révèle un phénomène culturel plus profond au sein de la communauté AutoCAD®. Il ne s’agit pas seulement de développeurs cachant des secrets ; il s’agit d’un sens de l’humour partagé, d’un désir de briser la monotonie d’un travail hautement technique et d’une aspiration à une connexion plus personnelle avec les outils qu’ils utilisent quotidiennement. Le fait que les utilisateurs recherchent avec enthousiasme et même tombent dans le piège de farces élaborées indique un lien émotionnel fort et une affection pour le logiciel au-delà de son utilité fonctionnelle. Ces aspects « cachés » remplissent une fonction sociale, favorisant un sentiment de connaissance privilégiée, d’expérience partagée et d’interaction ludique entre le logiciel et ses utilisateurs dévoués.
3.2 Malice faite par l’utilisateur : utiliser AutoCAD® pour les farces de bureau
La profonde configurabilité et l’accès étendu à la ligne de commande d’AutoCAD®, souvent via des variables système moins connues, en font un terrain fertile pour des farces de bureau inoffensives (et parfois moins inoffensives). Celles-ci sont « cachées » dans le sens où elles exploitent des paramètres obscurs pour créer un comportement inattendu et souvent frustrant pour des collègues sans méfiance.
NOMUTT
(Pas d’invites de saisie) : Régler la variable systèmeNOMUTT
à 1 (Vrai) désactive toutes les invites de saisie dans la fenêtre de commande.7 Cela peut être incroyablement désorientant pour les utilisateurs qui dépendent de ces invites pour se guider pendant l’exécution des commandes, rendant même les tâches simples confuses.SNAPANG
(Dessin Incliné) : L’une des farces les plus insidieuses consiste à régler la variable systèmeSNAPANG
à un petit incrément non nul (par exemple, 0,25 degré).8 Cela fait que tout ce qui est dessiné est légèrement incliné, même lorsque le mode Ortho est actif, rendant un utilisateur fou alors qu’il essaie de tracer des lignes parfaitement droites.- Farce de la Couleur du Curseur : Un classique visuel consiste à changer la couleur du curseur AutoCAD® pour qu’elle corresponde à la couleur de fond (par exemple, des réticules noirs sur un fond noir).8 Cela rend le curseur effectivement invisible, causant une immense frustration alors que l’utilisateur lutte pour localiser son pointeur. Cela se fait via la boîte de dialogue
OPTIONS
, sous l’onglet Affichage, dans les paramètres de Couleurs. - Astuce
LIMITS
: La commandeLIMITS
, souvent oubliée dans la CAO moderne, peut être exploitée. En définissant les limites du dessin sur une très petite zone (par exemple,0,0
à1,1
) puis en activantLIMITS
(ON), l’utilisateur sera empêché de dessiner en dehors de cette petite limite, générant une erreur « Hors limites » chaque fois qu’il essaiera de dessiner normalement.14 BLIPMODE
Activé : L’activation deBLIPMODE
fait qu’AutoCAD® place un signe « + » (un « blip ») partout où l’utilisateur clique.14 Ces blips persistent jusqu’à l’exécution d’une commandeREGEN
, créant une expérience visuellement encombrée et agaçante.-TOOLBAR ALL SHOW
: Cette variante en ligne de commande (utilisant le trait d’union pour contourner la boîte de dialogue) affiche chaque barre d’outils connue d’AutoCAD®, encombrant complètement l’interface et submergeant l’utilisateur sous une mer d’icônes.14 La solution, heureusement, est généralement aussi simple que de restaurer un espace de travail préféré.ERASE ALL
puisQSAVE
deux fois : Il s’agit d’une farce très malveillante et destructrice. Elle efface l’intégralité du dessin (ERASE ALL
) puis l’enregistre deux fois (QSAVE QSAVE
), écrasant non seulement le fichier DWG™ actuel mais aussi le fichier de sauvegarde précédent (.BAK
).14 Avertissement : Cette farce est extrêmement destructrice et ne doit jamais être tentée, car elle peut entraîner une perte de données irréversible et de graves conséquences.- Commande
UNDEFINE
: La commandeUNDEFINE
est un autre outil incroyablement dangereux. Elle permet de désactiver n’importe quelle commande AutoCAD®. Par exemple,UNDEFINE LINE
pourrait être suivi de la redéfinition deLINE
pour pointer vers la commandeQQUIT
(qui quitte AutoCAD® sans enregistrer), entraînant une terminaison inattendue du programme.14 Avertissement : Cette commande est extrêmement puissante et potentiellement destructrice ; utilisez-la avec une extrême prudence ou évitez-la entièrement.
Le phénomène des farces de bureau met en lumière un principe fondamental de la conception logicielle : plus un outil est flexible et puissant, plus son potentiel d’utilisations intentionnelles et non intentionnelles est grand. Les fonctionnalités conçues pour un contrôle précis, le débogage ou l’automatisation, lorsque leur existence ou leurs paramètres spécifiques sont « cachés » à l’utilisateur moyen, deviennent des candidats parfaits pour une exploitation malicieuse. Cela souligne que la véritable maîtrise d’un logiciel complexe comme AutoCAD® implique non seulement la compréhension de ses fonctionnalités documentées, mais aussi de son architecture sous-jacente et des contrôles obscurs qui peuvent modifier considérablement son comportement, que ce soit pour la productivité ou la subversion ludique. C’est un témoignage de la profondeur d’AutoCAD® que même ses éléments « cachés » peuvent être pliés à la volonté de l’utilisateur de manière inattendue.
Tableau 3 : « Easter Eggs » et farces notables d’AutoCAD®
Nom/Description | Type | Activation/Contexte | Vérification (Réel/Canular) | Impact/Objectif | Avertissement |
---|---|---|---|---|---|
« Call of Duty Modern Warfare 3 » | Easter Egg (Canular) | Séquence complexe de frappes clavier et mouvements de souris dans AutoCAD® 2014. | Canular (Poisson d’Avril 2013) 11 | Humour de développeur, test de la crédulité des utilisateurs. | Aucun, sauf si l’on y croit trop sérieusement. |
« CAD-PAC » | Easter Egg (Canular) | Séquence spécifique de commandes dans AutoCAD® 2018/2017. | Canular (Poisson d’Avril 2017) 12 | Humour de développeur, clin d’œil à un jeu classique. | Aucun. |
Plugin Sokoban | Easter Egg (Réel) | Téléchargeable depuis l’Autodesk® App Store. | Réel 13 | Permet de jouer au jeu Sokoban dans AutoCAD® ; les utilisateurs peuvent créer des niveaux. | Aucun. |
NOMUTT |
Farce | Variable système réglée à 1. | Réel 7 | Supprime toutes les invites de commande, désorientant l’utilisateur. | Peut frustrer l’utilisateur, mais n’est pas destructeur. |
SNAPANG |
Farce | Variable système réglée à un petit angle non nul (ex: 0.25). | Réel 8 | Toutes les lignes sont légèrement inclinées, même avec Ortho activé. | Très frustrant, mais non destructeur. |
Curseur Invisible | Farce | Couleur du curseur assortie à la couleur de fond via OPTIONS. | Réel 8 | Rend le curseur invisible, rendant la navigation difficile. | Non destructeur. |
LIMITS Restreintes |
Farce | LIMITS définies sur une petite zone et activées. |
Réel 14 | Empêche le dessin en dehors d’une petite zone, générant des erreurs. | Non destructeur. |
BLIPMODE On |
Farce | BLIPMODE activé. |
Réel 14 | Affiche un « + » à chaque clic, encombrant l’écran jusqu’à REGEN . |
Non destructeur, mais visuellement agaçant. |
-TOOLBAR ALL SHOW |
Farce | Commande -TOOLBAR ALL SHOW . |
Réel 14 | Affiche toutes les barres d’outils, submergeant l’interface. | Facilement réversible en restaurant l’espace de travail. |
ERASE ALL puis QSAVE deux fois |
Farce | Séquence de commandes ERASE ALL puis QSAVE deux fois. |
Réel 14 | EFFACE LE DESSIN ET LA SAUVEGARDE DE SAUVEGARDE (.BAK). | EXTRÊMEMENT DESTRUCTEUR. NE JAMAIS TENTER. |
UNDEFINE |
Farce | Commande UNDEFINE suivie d’une redéfinition malveillante. |
Réel 14 | Peut désactiver des commandes essentielles ou les rediriger vers QQUIT . |
EXTRÊMEMENT DANGEREUX ET POTENTIELLEMENT DESTRUCTEUR. À UTILISER AVEC UNE EXTRÊME PRUDENCE OU À ÉVITER ENTIÈREMENT. |
Chapitre 4 : L’Arsenal de l’utilisateur avancé : fonctionnalités avancées et trésors cachés
4.1 Au-delà des bases : Blocs Dynamiques, CUI et automatisation LISP
Bien que n’étant pas strictement « cachées » au sens d’être non documentées, ces fonctionnalités sont souvent sous-utilisées par les utilisateurs moyens d’AutoCAD®, et pourtant, elles libèrent une puissance, une personnalisation et une efficacité immenses pour ceux qui les maîtrisent. Elles représentent une couche de contrôle plus profonde qui transforme AutoCAD® d’un outil de dessin en une plateforme de conception hautement adaptable.
Les Blocs Dynamiques sont un atout majeur pour les tâches de conception répétitives. Contrairement aux blocs standard, ils permettent aux utilisateurs de créer des éléments flexibles et réutilisables avec des paramètres ajustables tels que l’étirement, la rotation ou le retournement, sans avoir besoin de redéfinir ou de soumettre à nouveau le bloc. Cette fonctionnalité réduit considérablement le temps de dessin et simplifie les modifications de conception, éliminant le besoin de « reconstruire quelque chose à partir de zéro ». Ils sont inestimables pour créer des composants intelligents qui s’adaptent à différents contextes au sein d’un dessin.
La personnalisation de l’interface utilisateur (CUI) : La commande CUI
(Customize User Interface) est la porte d’entrée vers une personnalisation extraordinaire de l’environnement AutoCAD®. Les utilisateurs peuvent attribuer des raccourcis clavier aux commandes fréquemment utilisées, créer des barres d’outils personnalisées et adapter la disposition du ruban pour accéder plus rapidement à leurs fonctionnalités les plus importantes. Ce niveau de personnalisation permet non seulement de gagner du temps, mais aussi d’augmenter considérablement l’efficacité du flux de travail, rendant l’expérience de conception plus intuitive et agréable en reflétant le flux de travail unique de l’utilisateur.
Pour les utilisateurs avancés recherchant le niveau ultime de personnalisation et d’automatisation, l’automatisation LISP est la solution. Ce langage de programmation intégré permet aux utilisateurs de créer des commandes personnalisées et d’automatiser des opérations complexes et répétitives qui seraient autrement fastidieuses ou impossibles avec les outils standard. Des exemples incluent des scripts pour la gestion automatisée des calques, la configuration des dessins, le traçage par lots, ou même des routines LISP spécialisées comme stripmtxt
pour corriger les problèmes de justification de texte. LISP permet aux utilisateurs de créer des outils sur mesure adaptés précisément à leurs besoins spécifiques, étendant efficacement les capacités d’AutoCAD® bien au-delà de ses fonctionnalités prêtes à l’emploi.
Cette philosophie de conception d’Autodesk® va au-delà de la simple offre de fonctionnalités ; elle favorise activement un état d’esprit de « développeur citoyen » parmi sa base d’utilisateurs. En fournissant de puissants outils de personnalisation, AutoCAD® permet aux utilisateurs de transcender le rôle de simples opérateurs et de devenir des créateurs de leurs propres outils spécialisés et de leurs flux de travail automatisés. Cela a de profondes implications pour les adaptations spécifiques à l’industrie, permettant aux entreprises de développer des solutions hautement personnalisées qui s’intègrent de manière transparente à AutoCAD®. Cela transforme AutoCAD® en une plateforme flexible sur laquelle les utilisateurs peuvent créer des applications personnalisées, démocratisant efficacement le développement de logiciels pour des défis de conception et d’ingénierie spécifiques, plutôt que d’être simplement une application fixe.
4.2 Rationalisation du flux de travail : outils Express et commandes intelligentes
Les « Outils Express » d’AutoCAD® sont une collection d’outils de productivité très utiles qui, bien que n’étant pas toujours affichés de manière proéminente, offrent des commandes puissantes souvent négligées par de nombreux utilisateurs. Au-delà des Outils Express, plusieurs autres commandes intelligentes rationalisent considérablement les opérations de dessin quotidiennes.
OVERKILL
: Cet outil Express essentiel est inestimable pour nettoyer les dessins en supprimant les objets qui se chevauchent ou les doublons. Il aide à réduire la taille des fichiers, améliore les performances et assure la précision, ce qui le rend fortement recommandé avant d’imprimer ou d’exporter des fichiers.LAYWALK
: Autre outil Express puissant,LAYWALK
permet aux utilisateurs de visualiser le contenu de chaque calque d’un dessin un par un. Cela est exceptionnellement utile pour gérer des fichiers complexes avec de nombreux calques, permettant une analyse et une organisation rapides des vues de dessin.TXT2MTXT
: Cet outil Express convertit efficacement les objets texte à une seule ligne en texte multiligne (MTEXT), offrant une plus grande flexibilité de formatage.QSELECT
(Sélection Rapide) : La commandeQSELECT
est une bouée de sauvetage pour travailler avec de grands dessins.15 Elle permet une sélection et un filtrage rapides des objets en fonction d’attributs spécifiques tels que le type d’objet (ligne, polyligne, texte), la couleur, le calque ou le type de ligne. Cela permet de gagner un temps considérable par rapport à la sélection manuelle, en particulier dans les conceptions complexes.BURST
: Lorsque l’on doit séparer les éléments d’un objet ou d’un bloc, la commandeBURST
s’avère incroyablement utile. Contrairement à la commandeEXPLODE
standard,BURST
sépare les éléments tout en conservant les attributs d’origine du bloc, évitant ainsi la perte de données.SAVEALL
/CLOSEALL
: Ces commandes simples mais efficaces permettent aux utilisateurs d’enregistrer ou de fermer rapidement tous les dessins ouverts simultanément. Elles sont idéales pour gérer efficacement plusieurs fichiers de dessin, surtout lorsque l’on doit terminer rapidement.OOPS
: Comme cela a été abordé précédemment, cette « fonctionnalité oubliée » restaure le dernier objet supprimé, même si d’autres opérations ont été effectuées depuis la suppression.6 Elle agit comme un outil de récupération ciblé pour les suppressions accidentelles, plus spécifique qu’unUNDO
général.MSTRETCH
: Cette commande permet aux utilisateurs d’étendre ou d’étirer plusieurs lignes ou polylignes à la fois 18, accélérant considérablement les tâches de modification qui nécessiteraient autrement plusieurs opérations individuelles.CHSPACE
: Une commande très pratique,CHSPACE
est utile pour déplacer des annotations, des dimensions ou d’autres objets entre l’espace objet et l’espace papier en une seule opération rapide. Cela garantit une mise à l’échelle et un placement corrects sans ajustements manuels.
La présence de nombreuses commandes incroyablement puissantes pour améliorer l’efficacité, l’hygiène des données et le flux de travail (OVERKILL
, LAYWALK
, QSELECT
, BURST
, OOPS
), qui ne sont pourtant souvent pas mises en évidence dans l’interface utilisateur par défaut ou largement connues par les utilisateurs moyens, crée un paradoxe. Cela signifie que les utilisateurs passent à côté de fonctionnalités utiles. Ce phénomène crée un paradoxe où certaines des fonctionnalités les plus efficaces d’AutoCAD® pour gagner du temps et améliorer la qualité restent des « trésors cachés » pour ceux qui ne les recherchent pas activement, n’apprennent pas des communautés d’utilisateurs avancés ou ne se plongent pas dans des ensembles d’outils spécialisés comme les Outils Express. Cela suggère que la véritable maîtrise d’AutoCAD® ne réside souvent pas dans la connaissance de toutes les commandes, mais dans la connaissance des bonnes commandes obscures qui répondent aux problèmes courants. Cela implique une sorte de « poignée de main secrète » entre les utilisateurs avancés, où les gains d’efficacité sont souvent liés à des connaissances spécialisées qui ne sont pas immédiatement évidentes à partir de l’interface standard.
4.3 Visualiser et contrôler l’invisible : affichage avancé et animation
AutoCAD® offre des outils sophistiqués pour la visualisation et le contrôle de l’affichage qui vont au-delà de la gestion de base des calques, permettant aux utilisateurs de gérer précisément ce qui est vu et comment il est présenté, en particulier dans des contextes 3D.
ANIPATH
(Animation de Chemin de Mouvement) : Pour les modèles 3D,ANIPATH
est une fonctionnalité puissante, mais souvent négligée, qui permet aux utilisateurs de créer des animations de caméra époustouflantes le long de chemins prédéfinis. Les utilisateurs peuvent lier des caméras et des cibles à des points spécifiques ou suivre des chemins complexes (lignes, arcs, polylignes, splines), contrôler la fréquence d’images, la résolution et exporter l’animation vers divers formats vidéo comme AVI, MOV, MPG ou WMV. Le panneau Animations, où réside cette fonctionnalité, est notamment caché par défaut, ce qui en fait un véritable « trésor caché » pour des présentations 3D convaincantes.HIDETEXT
(Variable Système) : Bien que désormais documentée, l’utilité spécifique de la variable systèmeHIDETEXT
est souvent sous-estimée. Elle contrôle si les objets texte créés par les commandesTEXT
ouMTEXT
sont traités (c’est-à-dire cachés) lors d’une commandeHIDE
.9 Cela permet des présentations visuelles plus propres des modèles 3D sans avoir besoin de basculer manuellement les calques de texte, garantissant que le texte n’obscurcit pas la géométrie sous-jacente.OBJECTISOLATIONMODE
(Variable Système) : Cette variable système cruciale détermine si les objets cachés ou isolés à l’aide des commandesISOLATEOBJECTS
ouHIDEOBJECTS
restent cachés entre les sessions de dessin. La définir à 1 garantit que les états de visibilité temporaires persistent après l’enregistrement et la réouverture du dessin, ce qui représente un gain de temps significatif pour maintenir la concentration sur des zones spécifiques au sein de dessins complexes sans avoir à ré-isoler les objets à chaque fois.VPCLIP
: Cette commande permet aux utilisateurs de modifier la forme d’une fenêtre, permettant la création de fenêtres non rectangulaires. Cela offre une plus grande flexibilité dans la mise en page et la présentation, permettant aux concepteurs de mettre en évidence des zones spécifiques d’un dessin de manière unique.TORIENT
/TJUST
: Ces commandes résolvent les problèmes courants de lisibilité du texte.TORIENT
peut rendre le texte illisible plus lisible en le réorientant, tandis queTJUST
permet aux utilisateurs de définir la justification de tout texte DTEXT ou MTEXT sélectionné sans déplacer physiquement l’objet texte. Ce sont des outils subtils mais efficaces pour maintenir la clarté du dessin.MSLTSCALE
: Introduite dans AutoCAD® 2008/2009, cette variable système met à l’échelle les types de ligne affichés sur l’onglet du modèle en fonction de l’échelle d’annotation. Cela élimine le besoin fastidieux d’ajustements manuels deLTSCALE
lors du passage entre l’espace objet et l’espace papier, carMSLTSCALE
gère automatiquement les échelles de ligne. C’est une amélioration significative de la qualité de vie pour une apparence cohérente des types de ligne à différentes échelles.
La tendance à rendre des fonctionnalités avancées et spécialisées moins visibles dans l’interface utilisateur, tout en les rendant accessibles aux utilisateurs expérimentés qui savent où les chercher, suggère une philosophie de conception délibérée. Cette approche vise à offrir une interface utilisateur épurée et intuitive pour les tâches quotidiennes, tout en fournissant des contrôles plus techniques et approfondis à ceux qui ont besoin de repousser les limites du logiciel. Cela reconnaît que tous les utilisateurs n’ont pas besoin que chaque fonctionnalité soit présentée d’emblée, et que le terme « caché » peut parfois signifier « contrôle de niveau expert » plutôt qu’« artefact oublié ».
Chapitre 5 : Bogues, curiosités et innovations accidentelles
5.1 Quand les problèmes deviennent des fonctionnalités : la philosophie « Ce n’est pas un Bug, c’est une Fonctionnalité »
L’adage « Ce n’est pas un bug, c’est une fonctionnalité » (INABIAF) est une expression courante, souvent humoristique, dans le développement logiciel. Il décrit des situations où une bizarrerie logicielle, plutôt que d’être corrigée, est soit documentée comme un comportement intentionnel, soit même adoptée comme une caractéristique bénéfique. La longue histoire d’AutoCAD® fournit des exemples convaincants de cette approche pragmatique de l’évolution logicielle.
Dans AutoCAD® 2016, une nouvelle fonctionnalité a été introduite permettant aux onglets de modèle/présentation de se déplacer dynamiquement sur une deuxième ligne s’ils devaient autrement interférer avec la barre d’état. Bien que destinée à une meilleure adaptabilité de l’interface utilisateur, cela a souvent conduit à un scintillement, un clignotement ou un saut persistant et gênant de la fenêtre de dessin, en particulier lorsque la barre d’état se trouvait au seuil précis entre l’affichage sur une et deux lignes. Au lieu de supprimer complètement la fonctionnalité, Autodesk® a fourni une variable système, STATUSBARAUTOWRAP
, qui pouvait être définie sur Off
ou 0
. Cela a effectivement transformé le comportement problématique en une fonctionnalité configurable par l’utilisateur, permettant à ceux qui étaient gênés par le scintillement de le désactiver, illustrant ainsi la philosophie INABIAF en donnant aux utilisateurs le contrôle sur la « bizarrerie ».
Bien que non spécifique à AutoCAD®, l’histoire de la fonction « Annuler l’envoi » de Gmail illustre parfaitement le principe INABIAF. Elle est née d’un délai de traitement de 5 secondes lors de l’envoi d’un courriel. Au lieu d’éliminer le délai, les développeurs ont intelligemment implémenté une option « Annuler », transformant une limitation technique en une fonctionnalité très appréciée par l’utilisateur. Cela démontre comment les problèmes perçus peuvent être recontextualisés et exploités au profit de l’utilisateur. Un autre exemple classique de l’histoire du logiciel est la convention de masquer les fichiers qui commencent par un point (.
) dans les systèmes Unix/Linux. Cela aurait été une conséquence involontaire de la conception précoce du système de fichiers qui n’a jamais été « corrigée » mais est devenue une « fonctionnalité » acceptée et utile pour les utilisateurs afin de masquer les fichiers de configuration et d’autres données moins fréquemment consultées. Ces analogies mettent en évidence un fil conducteur commun dans le développement logiciel où les décisions pragmatiques conduisent à des fonctionnalités inattendues, mais utiles.
L’approche consistant à fournir une option configurable par l’utilisateur pour un comportement problématique reflète une stratégie pragmatique et centrée sur l’utilisateur dans l’évolution des logiciels. Lorsqu’un « bug » est profondément lié à une nouvelle fonctionnalité ou à une interaction système complexe, une correction complète pourrait être disproportionnellement coûteuse, introduire de nouvelles instabilités ou retarder les versions. Au lieu de cela, fournir une option configurable par l’utilisateur (comme STATUSBARAUTOWRAP
) transforme efficacement le comportement problématique en un choix. Cela privilégie la stabilité globale du système et le contrôle de l’utilisateur plutôt qu’une « pure » correction de bogue, permettant aux utilisateurs d’adapter le logiciel à leurs préférences. C’est une application nuancée de la philosophie « ce n’est pas un bug, c’est une fonctionnalité », où la « fonctionnalité » est le choix de gérer la bizarrerie, plutôt que la bizarrerie elle-même.
5.2 Naviguer dans l’imprévisible : problèmes courants et solutions communautaires
Aucun logiciel complexe n’est entièrement exempt de bogues, et AutoCAD® ne fait pas exception. Au cours de sa longue histoire, les utilisateurs ont rencontré diverses anomalies, ce qui a conduit au développement d’un riche corpus de solutions de contournement pilotées par la communauté qui font souvent partie de la base de connaissances partagée et non documentée.
Au-delà du problème de STATUSBARAUTOWRAP
, le scintillement, le clignotement ou le saut de la fenêtre de dessin peuvent également être causés par des problèmes de carte graphique, des pilotes vidéo obsolètes ou des conflits avec des moniteurs haute résolution (4K). Les solutions développées par la communauté incluent la mise à jour des pilotes graphiques, la configuration des cartes graphiques doubles pour utiliser l’option haute performance, la désactivation de l’accélération matérielle, ou même le retour à une version DirectX précédente.
Les utilisateurs signalent parfois l’apparition d’un ensemble de lignes apparemment aléatoires lors de l’ouverture d’un dessin. Ce problème est souvent attribué à des comportements spécifiques de la carte graphique. Les solutions de contournement incluent la désactivation de la variable système LINESMOOTHING
et, pour les versions plus anciennes (2016/2017), la désactivation de la variable système HQGEOM
(High-Quality Geometry).
Un problème courant et frustrant est lorsque les fichiers DWG™ deviennent inopinément en lecture seule. Les causes incluent souvent des problèmes de synchronisation de fichiers hors ligne, des conflits avec des solutions de stockage cloud (comme Dropbox, Google Drive, OneDrive) ou des autorisations de fichier incorrectes.28 Les solutions de contournement communautaires incluent l’utilisation de SAVE AS
sous un nouveau nom, la définition d’un chemin local pour les fichiers BAK via l’outil Express MOVEBAK
, la définition de ISAVEBAK
à 0 (pour désactiver les fichiers de sauvegarde), ou ISAVEPERCENT
à 0 (pour forcer les sauvegardes complètes, empêchant les sauvegardes ajoutées qui peuvent causer des problèmes).
Les utilisateurs constatent parfois que leurs barres d’outils ou leur ruban AutoCAD® ont disparu.17 Les correctifs courants, largement partagés sur les forums, impliquent de vérifier s’ils sont simplement masqués, de réinitialiser le ruban (RIBBONCLOSE
suivi de RIBBON
), de définir la variable système MENUBAR
à 1, ou de personnaliser les espaces de travail via la commande CUI
.
Une frustration persistante pour certains utilisateurs est l’incapacité de tracer des lignes parfaitement droites, souvent liée à des paramètres de système de coordonnées utilisateur (UCS) incorrects, des valeurs SNAPANG
involontaires (comme on le voit dans les farces), ou le fait de s’accrocher à des grilles qui décalent subtilement les points d’extrémité. Les conseils de la communauté impliquent généralement la vérification et la réinitialisation des paramètres UCS
, en s’assurant que SNAPANG
est à 0, et en vérifiant que FILEDIA
est à 1 si les boîtes de dialogue d’enregistrement sont manquantes.
Pour les erreurs visuelles dans les dessins 3D, la commande REGEN3
est un conseil communautaire connu pour forcer une régénération et souvent résoudre les problèmes d’affichage. Lorsque l’on traite des bords ou des coins déconnectés d’un profil 2D, la séquence PEDIT
(Polyline Edit) > M
(Multiple) > JOIN
> JOINTYPE
> BOTH
> 1.0
(distance de flou) est une solution de contournement courante pour les connecter.
La communauté d’utilisateurs d’AutoCAD® fonctionne comme un système de support puissant, non officiel et distribué. Lorsque la documentation officielle ou les correctifs immédiats font défaut, les utilisateurs identifient collectivement les problèmes, expérimentent des solutions et partagent leurs découvertes, conduisant souvent à des solutions de contournement robustes qui deviennent des connaissances courantes. Cela met en évidence une relation symbiotique critique où la base d’utilisateurs comble les lacunes du support officiel et contribue de manière significative à l’utilisabilité pratique et à la résilience du produit grâce à l’expérience partagée et à l’ingéniosité. Cette intelligence collective forme essentiellement une « fonctionnalité cachée » de l’expérience AutoCAD® elle-même, offrant une couche vitale de résolution de problèmes qui s’étend au-delà des offres directes du fournisseur.
5.3 Le facteur humain : résistance au changement et évolution des meilleures pratiques
L’adoption de nouvelles fonctionnalités dans un logiciel mature comme AutoCAD® n’est pas seulement un défi technique ; elle est profondément influencée par des facteurs humains, la culture organisationnelle et les habitudes ancrées. Des anecdotes provenant de forums d’utilisateurs révèlent une forte mentalité de « nous avons toujours fait comme ça » chez certains utilisateurs d’AutoCAD® de longue date, ce qui conduit à une résistance significative à l’adoption de nouvelles fonctionnalités, même bénéfiques.
De nombreux utilisateurs, en particulier ceux qui utilisent AutoCAD® depuis des décennies, sont profondément ancrés dans leurs habitudes. Les histoires abondent de bureaux où les nouvelles recrues sont « grondées pour avoir utilisé toute nouvelle fonctionnalité introduite après 2004 ». Cette résistance découle souvent d’un confort avec les commandes et scripts personnalisés existants qui peuvent ne pas être compatibles avec les nouvelles fonctionnalités. Des exemples incluent l’adoption lente des blocs dynamiques et des tableaux associatifs, malgré leur utilité significative.
Cette résistance peut être institutionnalisée, avec des « responsables de dessin » qui dictent l’adhésion à des conventions de nommage de calques obsolètes ou refusent catégoriquement d’utiliser des fonctionnalités comme les Xrefs, même lorsqu’elles offrent des gains d’efficacité évidents. La mentalité du « nous avons toujours fait comme ça » est décrite comme une « maladie » dans certaines discussions.
Au-delà des habitudes individuelles, des décisions commerciales plus larges peuvent également avoir des conséquences imprévues. La « disparition de la licence réseau multi-utilisateur d’AutoCAD® », par exemple, aurait « accéléré le succès de son principal concurrent au Japon et en Asie ». Cela illustre comment les changements de politique, même s’ils ne sont pas directement liés aux fonctionnalités, peuvent se répercuter sur l’écosystème, influençant le comportement des utilisateurs et la dynamique du marché de manière imprévue.
Ce phénomène met en évidence que l’adoption réussie de nouvelles fonctionnalités dans un logiciel mature et profondément intégré comme AutoCAD® n’est pas seulement un défi technique (c’est-à-dire faire en sorte que la fonctionnalité fonctionne bien), mais un défi socio-technique complexe. Il ne suffit pas qu’une fonctionnalité soit objectivement meilleure ; elle doit surmonter les habitudes profondément ancrées des utilisateurs, les flux de travail personnalisés existants (souvent construits sur LISP ou des scripts plus anciens) et l’inertie organisationnelle. Cela implique que les fonctionnalités « cachées » peuvent rester cachées non seulement parce qu’elles ne sont pas documentées, mais parce que la base d’utilisateurs résiste activement (ou passivement) à leur intégration dans les pratiques établies. Cela a des implications significatives sur la manière dont les éditeurs de logiciels introduisent et promeuvent de nouvelles fonctionnalités, suggérant que la supériorité technique seule ne suffit pas à une adoption généralisée, et que la compréhension de la psychologie des utilisateurs et des flux de travail existants est primordiale.
Conclusion : L’attrait durable des profondeurs cachées d’AutoCAD®
Du début modeste de « Interact » à son statut actuel de norme industrielle, le parcours d’AutoCAD® est riche en histoires fascinantes, en empreintes de développeurs et en innovations impulsées par les utilisateurs. Ce rapport a exploré des commandes qui « ne font rien » mais offrent un sourire, des variables système qui révèlent une logique interne et des mesures anti-piratage, des poissons d’avril devenus des légendes urbaines, et des fonctionnalités puissantes qui restent cachées à la vue de tous. Il a été montré comment l’absence d’une fonction « annuler » dans le passé a stimulé l’innovation, comment la réaction du marché a façonné le destin d’une entreprise, et comment même les « bogues » peuvent évoluer en fonctionnalités utiles.
Comprendre ces trésors cachés, ces particularités et ces anecdotes ne consiste pas seulement à satisfaire la curiosité ou à gagner des concours de trivia ; il s’agit de débloquer de nouveaux niveaux de productivité, de résoudre des problèmes complexes avec des connaissances d’initié et d’acquérir une profonde appréciation de l’ingénierie complexe et des facteurs humains derrière cet outil de conception omniprésent. Le monde « caché » d’AutoCAD® témoigne de sa complexité durable, de son adaptabilité et de la communauté dynamique qui continue d’explorer chaque recoin, repoussant ses limites et assurant sa pertinence continue dans le monde en constante évolution de la conception.