SOLIDWORKS PDM lent : les 7 vraies causes (et la 6ᵉ que personne ne regarde)
Publié le 18 juin 2026 — chaque ouverture d'assemblage qui traîne, c'est un ingénieur qui décroche. Voici pourquoi votre coffre rame vraiment, et comment récupérer 15 minutes par jour et par poste.
« On a acheté des stations à 4 000 € et ça rame toujours. » C'est la phrase que j'entends en réunion de lancement une fois sur deux. L'entreprise a investi dans du matériel, l'informatique jure que « le réseau est en gigabit », et pourtant ouvrir un gros assemblage prend deux minutes. Les ingénieurs, eux, ont arrêté de se plaindre. Ils vont chercher un café pendant le check-out. Multipliez ces cafés par 15 personnes et 220 jours ouvrés : vous perdez l'équivalent d'un poste et demi à temps plein, chaque année, sans qu'une seule ligne de budget ne le montre.
La bonne nouvelle, c'est que la lenteur d'un SOLIDWORKS PDM n'est presque jamais un mystère. C'est une chaîne — station, réseau, serveur d'archives, base SQL, antivirus, cartes de données — et il suffit qu'un maillon lâche pour que tout ralentisse. Après 100+ projets PDM, j'ai fini par toujours regarder les mêmes 7 endroits, dans le même ordre. Le 6ᵉ est celui que même les intégrateurs oublient. Prenez dix minutes : à la fin de cet article, vous saurez exactement où poser votre doigt lundi matin.
Avant de commencer : notez le temps que met votre plus gros assemblage à s'ouvrir en local (fichier hors coffre) puis depuis le coffre. L'écart entre les deux est votre vrai diagnostic. Gardez ce chiffre sous les yeux, on y revient à la fin.
1. Le serveur d'archives sous-dimensionné
SOLIDWORKS PDM repose sur deux serveurs : le SQL Server (métadonnées, workflows, recherches) et l'Archive Server (stockage et service des fichiers physiques). Quand ça rame à l'ouverture ou au check-out, c'est presque toujours l'Archive Server qui souffre — et c'est presque toujours celui qu'on a installé « en attendant » sur une vieille VM partagée avec trois autres services.
Ce serveur transfère des gigaoctets de fichiers CAO toute la journée. Si son disque est un HDD 7200 tr/min, si sa carte réseau est en 1 Gbit/s partagé, ou s'il tourne sur une VM avec 4 Go de RAM, il devient le point d'étranglement de toute l'entreprise. Vos stations à 4 000 € attendent poliment.
Chez un fabricant de machines spéciales, l'Archive Server tournait sur la même VM que la messagerie et la GED. On l'a isolé sur un hôte dédié avec un SSD NVMe et une carte 10 Gbit/s. Temps d'ouverture du plus gros assemblage : de 1 min 50 à 22 secondes. Zéro modification côté SOLIDWORKS.Mohamed Omar Baouch
Ce qu'il faut vérifier : disque en SSD (NVMe idéalement) pour le dossier des archives, RAM suffisante, carte réseau dédiée, et surtout — l'Archive Server ne partage pas ses ressources avec un autre service gourmand. C'est le premier levier, et souvent le seul nécessaire.
2. Le cache local mal réglé
Le principe même du PDM, c'est de travailler en local sur une copie cachée, pas de tirer les fichiers du serveur à chaque clic. Si vos ingénieurs voient un téléchargement se déclencher à chaque ouverture de fichiers pourtant ouverts hier, votre cache est mal géré.
- Cache purgé trop agressivement — des scripts vident le cache local chaque nuit « pour faire de la place ». Résultat : tout se retélécharge chaque matin.
- « Get Latest Version » systématique — toute la référence est retirée à chaque ouverture au lieu de s'appuyer sur la version en cache.
- Disques locaux saturés — un cache sur un disque système plein rame mécaniquement.
Le bon réglage : un cache local sur SSD, une politique de purge raisonnée (garder les projets actifs), et l'usage de la réplication d'archives pour les sites distants. Ce qui nous amène au maillon suivant.
3. L'antivirus qui scanne le coffre — le tueur silencieux
Voici la cause la plus fréquente et la plus invisible. L'antivirus de vos postes — et surtout celui du serveur — scanne en temps réel chaque fichier lu ou écrit. Or un check-in d'assemblage, c'est des milliers de petites opérations disque. L'antivirus les intercepte toutes, une par une.
Le symptôme typique : « c'est rapide le matin, ça devient lent en journée ». Ce n'est pas la charge réseau — c'est l'antivirus qui a démarré son analyse planifiée sur le dossier d'archives.
La solution est documentée par Dassault Systèmes et pourtant rarement appliquée : exclure du scan temps réel le cache local des stations, le dossier des archives du serveur, les processus SOLIDWORKS (sldworks.exe, EdmServer.exe, ViewServer.exe) et les fichiers de base SQL. Exclure ne veut pas dire baisser sa sécurité — cela veut dire scanner ces données au bon endroit (à la source) plutôt que 50 fois par jour sur chaque poste.
4. La base SQL jamais maintenue
Le SQL Server pilote les recherches, les cartes de données, les transitions de workflow. Une base PDM qui tourne depuis cinq ans sans maintenance accumule des index fragmentés et des statistiques périmées. Les recherches deviennent lentes, l'ouverture des propriétés traîne.
- RAM SQL plafonnée trop bas — SQL Server adore la mémoire. Sur une base PDM active, 16 à 32 Go dédiés changent tout.
- Pas de plan de maintenance — reconstruction d'index et mise à jour des statistiques doivent tourner chaque semaine.
- Version Express en surcharge — SQL Express est limité à 10 Go et 1 Go de RAM. Au-delà de quelques dizaines d'utilisateurs, c'est un plafond de verre.
Un DBA (ou un intégrateur) met en place un plan de maintenance en une demi-journée. L'effet sur les recherches est immédiat et durable.
5. Le réseau et la latence — le gigabit qui ment
« On est en gigabit » ne veut rien dire tout seul. Ce qui compte pour un PDM, c'est le débit réel de bout en bout et surtout la latence. Un site distant relié en VPN à 30 ms de latence peut rendre le coffre inutilisable, même avec un « gros débit », parce que le protocole multiplie les allers-retours.
Pour les sites multiples, la réponse n'est pas « plus de débit » mais un serveur d'archives répliqué sur chaque site : chaque équipe travaille sur sa copie locale, la réplication synchronise en tâche de fond. C'est la seule architecture qui tienne pour un BE réparti sur plusieurs villes.
6. Les cartes de données trop lourdes — celle que personne ne regarde
Voici la cause que même les intégrateurs oublient, parce qu'elle ne se voit pas dans les logs serveur. Les cartes de données — ces formulaires qui s'affichent quand on sélectionne un fichier — peuvent contenir des listes déroulantes alimentées par des requêtes SQL live, des contrôles avec des centaines de valeurs, des logiques de saisie conditionnelle en cascade.
Un client se plaignait que « cliquer sur un fichier lag ». Ni le serveur, ni le réseau n'étaient en cause. La carte de données contenait une liste « Fournisseur » branchée sur une requête SQL non filtrée qui ramenait 12 000 lignes… à chaque clic sur chaque fichier. On a mis la liste en cache : lag disparu.Mohamed Omar Baouch
Si tout le reste est sain et que la sélection d'un fichier reste poussive, ouvrez l'éditeur de cartes : listes dynamiques, valeurs par défaut coûteuses, contrôles inutiles. Alléger une carte prend une heure et se ressent par chaque utilisateur, toute la journée.
7. Les références et la structure des dossiers
Parfois, ce n'est pas le PDM — c'est la CAO qu'il doit gérer. Des assemblages de milliers de composants, des références circulaires, des fichiers dupliqués sous plusieurs noms, une Toolbox mal configurée qui régénère des milliers de vis à chaque ouverture : le PDM ne fait que subir.
- Toolbox hors coffre ou dupliquée — la source n°1 de références cassées et de lenteurs d'ouverture.
- Assemblages « plats » de 5 000 pièces sans sous-assemblages — chaque ouverture recharge tout.
- Fichiers hors coffre référencés — le PDM cherche, ne trouve pas, attend, recommence.
Ici le correctif est méthodologique : structurer la Toolbox, découper les gros assemblages, rapatrier toutes les références dans le coffre. C'est du travail de fond, mais c'est aussi ce qui empêche le problème de revenir.
Reprenez votre chiffre de départ
Vous vous souvenez de l'écart que je vous ai demandé de noter au début — temps d'ouverture en local vs depuis le coffre ? Voici comment le lire :
Écart faible (quelques secondes)
Votre infrastructure PDM est saine. Cherchez du côté de la CAO elle-même : cause n°7, Toolbox, poids des assemblages.
Écart énorme (× 3 ou plus)
Le problème est dans la chaîne serveur/réseau/antivirus : causes 1, 3 et 5. Commencez par exclure l'antivirus, c'est gratuit et immédiat.
L'ordre d'attaque qui rapporte le plus vite : (1) exclusions antivirus, (2) isoler et accélérer l'Archive Server, (3) plan de maintenance SQL. Ces trois actions couvrent 70 % des cas et ne demandent aucun changement dans les habitudes des ingénieurs — juste un serveur qui respire enfin.
Un PDM rapide, ce n'est pas un luxe d'IT. C'est 15 minutes rendues chaque jour à chaque ingénieur, des check-in qu'on ne repousse plus « parce que c'est long », et une équipe qui fait enfin confiance à son coffre. Le matériel, vous l'avez déjà payé. Il ne demande qu'à tourner à pleine vitesse.
Questions fréquentes
Pourquoi SOLIDWORKS PDM est-il lent ?
Dans l'ordre de fréquence : la base SQL mal dimensionnée ou non maintenue, le réseau entre le poste et le serveur d'archives, le cache local mal purgé, l'antivirus qui analyse chaque fichier, et les cartes de données ou workflows trop complexes. Le modèle CAO lui-même est rarement le coupable.
Comment savoir si le problème vient du réseau ou du poste ?
Mesurez la même opération sur un poste vide de cache puis sur un poste déjà en cache : si l'écart est massif, le trajet réseau est en cause. Comparez ensuite avec un poste situé sur le même segment que le serveur. Sans mesure, on remplace du matériel au hasard.
Faut-il exclure le coffre de l'antivirus ?
Les dossiers du coffre, le cache local et les répertoires d'archives méritent des exclusions ciblées, à faire valider par votre informatique. L'analyse temps réel sur des milliers de fichiers CAO produit des ralentissements spectaculaires et des échecs d'enregistrement.
Ajouter de la RAM résout-il la lenteur du PDM ?
Rarement, parce que le problème n'est presque jamais sur le poste. La mémoire aide la CAO ; la lenteur du coffre se joue sur la base de données, le réseau et le stockage du serveur. Mesurez avant d'acheter.