Comparaison entre une macro AutoCAD et une routine AutoLISP pour illustrer la lisibilité, la maintenance et l'évolutivité des automatisations.

AutoCAD & AutoCAD LT : quand une macro devient-elle une usine à gaz ?

Last Updated on 15 novembre 2026 by Didier Lourdelle

J’utilise AutoCAD depuis plus de 35 ans, et les macros de commandes font toujours partie de mes outils de personnalisation.

Pour mettre au point une automatisation, je commence souvent par une palette d’outils. C’est rapide, pratique et cela évite de développer inutilement une routine.

Mais avec l’expérience, j’ai adopté une règle simple :

Dès que je commence à copier-coller une macro pour en créer plusieurs variantes en changeant seulement quelques paramètres, je me pose la question du passage à AutoLISP.

Pourquoi ?
Parce qu’une automatisation ne doit pas seulement fonctionner aujourd’hui. Elle doit aussi rester compréhensible et facile à modifier dans six mois, un an ou davantage.

Que se passe-t-il lorsque la personne qui a créé les macros quitte l’entreprise et que personne ne sait exactement comment elles fonctionnent ?

1. Les macros : un excellent point de départ

Les macros permettent d’enchaîner des commandes AutoCAD et de transmettre automatiquement certains paramètres.

Associées aux palettes d’outils, elles constituent une solution particulièrement efficace pour créer des commandes personnalisées.

  • Mise au point rapide.
  • Pas de langage de programmation à maîtriser.
  • Accès direct aux commandes depuis une palette.
  • Déploiement relativement simple auprès des utilisateurs.
  • Automatisation de tâches répétitives avec des paramètres prédéfinis.

Pour une action simple, une macro peut parfaitement répondre au besoin pendant des années.

Le problème apparaît lorsque les variantes se multiplient et que la même séquence doit être modifiée à plusieurs endroits.

2. Exemple avec la commande DECALER d’AutoCAD

Prenons un exemple volontairement simple : la commande DECALER (OFFSET).

Imaginons que nous souhaitions disposer de sept distances de décalage prédéfinies :

10, 20, 30, 40, 50, 65 et 90 unités.

La première solution consiste à créer sept outils dans une palette, chacun exécutant une macro :

Décalage 10 : ^C^C_.OFFSET;10;
Décalage 20 : ^C^C_.OFFSET;20;
Décalage 30 : ^C^C_.OFFSET;30;
Décalage 40 : ^C^C_.OFFSET;40;
Décalage 50 : ^C^C_.OFFSET;50;
Décalage 65 : ^C^C_.OFFSET;65;
Décalage 90 : ^C^C_.OFFSET;90;

Chaque macro lance la commande DECALER avec une distance fixe. L’utilisateur poursuit ensuite avec la sélection de l’objet et l’indication du côté.

À ce stade, rien de compliqué. Et franchement, pourquoi programmer davantage ?

Mais supposons que le besoin évolue.

  • Proposer plusieurs distances dans une seule commande.
  • Afficher une valeur par défaut.
  • Mémoriser la dernière distance sélectionnée.
  • Limiter les choix aux valeurs autorisées.
  • Éviter de multiplier les outils et les macros.
  • Faire évoluer ultérieurement le fonctionnement.

Nous ne sommes plus simplement dans l’exécution d’une séquence de commandes. Nous commençons à définir un comportement.

3. Passer à AutoLISP sans compliquer les choses

Le passage à AutoLISP peut être très progressif.

Commençons par reproduire le fonctionnement d’une macro avec une commande AutoLISP :

(defun c:EDPS_DECALER_10 ()
  (command "_.OFFSET" 10)
  (princ)
)

Cette routine lance simplement DECALER avec une distance de 10 unités.

Elle n’apporte pas encore d’avantage fonctionnel significatif par rapport à la macro d’origine.

En revanche, nous avons désormais un point de départ pour introduire progressivement des variables, des conditions, des fonctions et des interactions utilisateur.

Le but n’est pas de convertir toutes les macros en AutoLISP, mais de disposer d’une base évolutive lorsque le besoin le justifie.

Pages : 1 2 3