Last Updated on 26 août 2026 by Didier Lourdelle

Après plus de trente ans passés autour d’AutoCAD, je continue à rencontrer la même question sous des formes différentes : faut-il former les utilisateurs ou développer l’outil qui leur manque ?

Sur le papier, la séparation paraît simple. La formation transmet des compétences. Le développement produit une commande, une interface ou un plugin. Dans la réalité d’une entreprise, la frontière est beaucoup moins nette.

Un projet récent, que je présente ici sans nommer le client ni son secteur, me l’a encore rappelé.

Au départ, la demande portait bien sur la programmation

La demande initiale concernait une formation très spécifique à la programmation AutoCAD. L’entreprise disposait déjà de plusieurs routines AutoLISP, mais aucune procédure standardisée ne permettait de déployer et de maintenir cette personnalisation sur un parc appelé à atteindre une vingtaine de postes.

Le contexte était rendu plus complexe par la fusion de deux structures. Chacune utilisait ses propres applications et une configuration AutoCAD adaptée à son fonctionnement. Après la fusion, ces deux personnalisations n’étaient pas compatibles et ne pouvaient pas être réunies simplement dans un même environnement. Selon les besoins, il fallait donc utiliser deux postes de travail distincts ou deux sessions Windows configurées différemment.

L’utilisation des routines reposait encore principalement sur le chargement des fichiers LISP. Certaines commandes étaient accessibles depuis des barres d’outils créées en interne, mais très peu d’interfaces utilisateur avaient été développées pour guider les opérations et simplifier l’utilisation des programmes.

L’objectif de la formation était donc double : permettre aux participants de mieux comprendre les programmes AutoLISP existants afin de pouvoir les maintenir et les faire évoluer, mais aussi leur apprendre à créer des interfaces adaptées aux besoins des utilisateurs. L’ensemble devait ensuite pouvoir être regroupé dans un véritable plugin d’entreprise.

L’audit a modifié le contenu de la formation

Je n’ai pourtant pas commencé par dérouler un cours théorique sur AutoLISP. La première étape a consisté à évaluer les connaissances des participants, puis à analyser avec eux la personnalisation existante : les routines chargées, les commandes disponibles, les barres d’outils, les fichiers utilisés, les différences de configuration issues des deux structures et la manière dont l’ensemble était installé sur les différents postes.

Cette première phase, qui a représenté environ deux jours et demi, leur a permis de reprendre progressivement la maîtrise de leur environnement de travail et de mieux comprendre le fonctionnement des routines déjà utilisées dans l’entreprise.

L’analyse a également révélé que certaines demandes présentées comme des besoins de programmation pouvaient être résolues avec des fonctionnalités natives d’AutoCAD encore méconnues. Une partie de la formation a donc été consacrée à une remise à niveau ciblée. Il aurait été contre-productif de développer des commandes spécifiques pour reproduire des fonctions qu’AutoCAD savait déjà réaliser correctement.

Ce n’est qu’ensuite que nous avons approfondi AutoLISP, travaillé sur la création d’interfaces utilisateur et étudié la manière de reprendre progressivement les fonctionnalités existantes dans un plugin structuré.

L’un des points qui a le plus surpris les participants concernait le déploiement. Lorsqu’un plugin est correctement organisé et packagé, les routines, les interfaces et les ressources communes peuvent être regroupées dans une même solution. Il devient alors possible de déployer une configuration commune, sans reconstruire manuellement la personnalisation sur chacun des vingt postes. Il n’est plus nécessaire de maintenir deux environnements de travail distincts et le passage à une nouvelle version d’AutoCAD devient également beaucoup plus simple à préparer.

Le plugin ne représente donc pas seulement une évolution technique des programmes existants. Il devient un moyen de réunir les outils issus des deux structures, de standardiser les méthodes de travail, de simplifier leur utilisation et de mieux maîtriser leur déploiement et leur maintenance.

Le code n’est pas toujours la première réponse

Une automatisation fiable repose sur un environnement suffisamment compris et stabilisé. Dans ce projet, cela signifiait notamment :

• inventorier les routines AutoLISP existantes et leurs dépendances ;
• identifier ce qui pouvait être traité avec les fonctionnalités natives d’AutoCAD ;
• distinguer les outils communs des règles propres à chacune des deux structures ;
• concevoir des interfaces communes pour simplifier l’utilisation des programmes ;
• organiser les fichiers et les ressources nécessaires au fonctionnement des commandes ;
• définir une méthode de déploiement et de mise à jour applicable à l’ensemble des postes.

Le langage et l’architecture technique n’interviennent qu’ensuite. Leur rôle est d’exécuter une méthode clarifiée, pas de masquer un environnement encore instable.

Un bon outil métier ne commence pas par la commande que l’on veut programmer, mais par la décision que l’utilisateur ne devrait plus avoir à répéter inutilement.

Documenter fait partie du résultat

La formation a également produit une matière importante qu’il fallait rendre durable et exploitable. Une séance enregistrée contient beaucoup d’informations, mais une vidéo de plusieurs heures reste difficile à utiliser lorsqu’il faut retrouver précisément une manipulation.

Les enregistrements et leurs transcriptions ont donc été transformés en pages de support interactives : vidéos, chapitres associés à des timecodes, points techniques, exercices et inventaire des fichiers utilisés.

À ce stade du projet, cela représente 19 pages de support, 16 séances chapitrées, 106 chapitres techniques et 20 vidéos intégrées.

Ce résultat est important à mes yeux. Le code seul peut devenir opaque. La documentation seule peut rester théorique. Lorsque l’outil, son explication et les fichiers d’exercice avancent ensemble, l’entreprise commence à constituer un véritable patrimoine technique.

Ce que cela change dans ma manière d’intervenir

Je ne vois plus la formation et l’accompagnement comme deux offres totalement séparées.

• La formation permet aux utilisateurs de comprendre, de tester et de devenir autonomes.
• L’accompagnement permet de cadrer le processus, de concevoir l’architecture, de développer les composants communs et d’organiser leur déploiement.
• La documentation assure la continuité entre les deux.

Selon le point de départ de l’entreprise, la démarche peut donc commencer par la formation et révéler un besoin de développement. Elle peut aussi commencer par un outil existant qu’il faut rendre compréhensible, transmissible et maintenable.

C’est précisément dans cette continuité que je situe aujourd’hui le Plugin Entreprise AutoCAD : non pas comme une accumulation de routines, mais comme un environnement commun construit autour des méthodes de l’équipe.

Une rencontre pour confronter cette démarche au terrain

Je présenterai des exemples concrets de cette démarche lors de la rencontre EDWGPROS Connect – Plugin Entreprise AutoCAD, le vendredi 18 septembre 2026, de 13 h 30 à 16 h 30 à Lille.

Le format est volontairement limité à 8 participants afin de laisser une vraie place aux questions, aux démonstrations et aux échanges sur les pratiques des bureaux d’études.