Optima ralentie après la mise à jour vers SQL Server 2025 ? Cause et solution

Après le passage de SQL Server 2022 à 2025, une nouvelle connexion à la base prenait 120 ms au lieu de 2 ms, et Optima se connecte à la base des centaines de fois. Nos mesures, la cause et la solution qui a fonctionné chez notre client.

Adrian Baczyński4 novembre 2026

Chez l’un de nos clients, la comptabilisation des documents dans Comarch ERP Optima a ralenti après la mise à jour de SQL Server de la version 2022 à la version 2025. Optima était déjà dans sa dernière version (2026.5) : seul le serveur de base de données a changé. Le serveur sous Windows Server 2019 héberge plusieurs centaines de bases de sociétés, et les salariés utilisent Optima surtout via le bureau à distance.

Symptômes

La comptabilisation de chaque document prenait 4 secondes, quel que soit son type : facture d’achat, facture de vente ou document KSeF. Un lot de documents prenait environ 49 secondes. Les salariés signalaient que des opérations qui duraient quelques secondes prenaient désormais des minutes.

Fenêtre « Comptabilisation du document » d’Optima : chaque document affiche un temps d’exécution de 00:00:04 — Fenêtre de comptabilisation d’Optima : 4 secondes par document. Numéros de documents et montants masqués.

Ce que nous avons vérifié et écarté

Avant de trouver la cause, nous avons mesuré le serveur pendant les heures de travail. Ces éléments fonctionnaient normalement :

Disque : lecture des données env. 0,2 ms, écriture du journal des transactions 3–4 ms.
Processeur : SQL Server utilisait en moyenne moins d’un cœur sur huit.
Verrous : aucun dans les mesures prises chaque seconde.
Réseau côté serveur : attentes d’env. 1 ms.
Antivirus : les exclusions Microsoft Defender pour SQL Server n’ont rien changé.

La cause : une vérification des mots de passe plus lente dans SQL Server 2025

SQL Server 2025 enregistre et vérifie les mots de passe des logins SQL avec l’algorithme PBKDF2 (100 000 itérations de SHA-512). Microsoft cite ce changement parmi les problèmes connus de SQL Server 2025, car il ralentit la connexion. Le serveur convertit lui-même les anciens mots de passe au nouveau format lors de la première connexion réussie après la mise à jour.

Selon nos mesures, une nouvelle connexion avec un login SQL prenait en moyenne 118,8 ms, contre 2,4 ms avec un compte Windows.

Pour une seule connexion, 120 ms ne compteraient pas. Optima se connecte avec le login SQL CDNOperator et ouvre un très grand nombre de nouvelles connexions : un lot de comptabilisation en a ouvert env. 166 en 49 secondes, et 15 minutes de travail normal du cabinet ont donné 2 481 connexions. Pour chacune, le serveur vérifie désormais le mot de passe de la nouvelle manière, plus lente.

Nous estimons que, dans un lot de 49 secondes, les connexions seules prenaient 12 à 20 secondes. Le reste correspond aux requêtes en base et au travail du programme lui-même. Les connexions expliquent donc une grande partie du retard, mais pas tout.

Comment vérifier si vous êtes concerné

Une seule requête dans SQL Server Management Studio suffit :

SELECT name, CONVERT(varchar(6), password_hash, 1) AS hash_type
FROM sys.sql_logins;

0x0300 signifie le nouveau format PBKDF2, et 0x0200 l’ancien format, rapide, de SQL Server 2022.

Ce qui a aidé : l’indicateur de trace 4671

Cette solution est expérimentale. L’indicateur de trace 4671 ne figure pas dans la documentation Microsoft, Microsoft ne le prend pas en charge, et certains spécialistes SQL le déconseillent. Chez notre client, il a fonctionné. Nous avons procédé dans cet ordre :

Sauvegarde complète de toutes les bases, y compris la base système master, qui contient les logins et les mots de passe. Beaucoup de scripts de sauvegarde simples ignorent les bases système.
Copie du password_hash actuel du login CDNOperator, pour pouvoir revenir à l’ancien mot de passe.
Test de l’indicateur sur un login de test temporaire, après les heures de travail.
Activation de l’indicateur avec DBCC TRACEON(4671, -1) et le paramètre de démarrage -T4671 dans SQL Server Configuration Manager, pour qu’il reste actif après un redémarrage.
Nouveau mot de passe CDNOperator défini dans Optima avec l’indicateur actif (Outils, Serveur de base de données, Changement du mot de passe de l’utilisateur « CDNOperator »), avec l’option « Enregistrer le mot de passe pour tous les utilisateurs Windows ». Optima doit être lancée en administrateur, sinon le fichier commun du mot de passe n’est pas mis à jour.
Nouveau mot de passe saisi sur chaque poste disposant de sa propre installation d’Optima, dans le service d’opérations automatiques et dans chaque programme qui utilise ce login.

Résultats sur le login de test (10 essais par étape) :

Sans l’indicateur : 118,8 ms par nouvelle connexion.
Indicateur actif, mot de passe encore au format PBKDF2 : 116,8 ms. La connexion seule ne change pas le format.
Indicateur actif et même mot de passe défini à nouveau : 0,8 ms.
Indicateur désactivé : 121,1 ms. La première connexion a reconverti le format en PBKDF2.

Fenêtre d’Optima « Connexion au serveur de bases de données » indiquant que le mot de passe du login CDNOperator a changé — La fenêtre que voit un salarié sur un poste avec sa propre Optima après le changement. Nom du serveur masqué.

Résultat

Une nouvelle connexion avec un login SQL est passée de 118,8 ms à 0,8 ms. La comptabilisation d’un document prend désormais env. 3 secondes au lieu de 4. C’est le résultat d’un seul test. Les salariés qui se connectent au serveur via le bureau à distance disent qu’Optima fonctionne beaucoup mieux. Nous n’avons pas encore comparé le même lot de documents avant et après la modification sur un même poste.

Points de vigilance

L’indicateur seul ne suffit pas. Il faut redéfinir le mot de passe pendant qu’il est actif.
Nous ne désactivons pas l’indicateur. Sans lui, SQL Server revient au PBKDF2 à la première connexion : le programme fonctionne, mais de nouveau lentement.
Après chaque mise à jour de SQL Server, nous vérifions l’indicateur et le format du mot de passe. Une prochaine mise à jour peut changer son fonctionnement. Chez nous, après la mise à jour de sécurité KB5126967, l’indicateur fonctionnait toujours.
Revenir à SQL Server 2022 n’est pas une issue simple : les bases et sauvegardes de SQL Server 2025 ne se restaurent pas sur la version 2022.
Les programmes qui se connectent encore avec l’ancien mot de passe apparaissent dans le journal de SQL Server (ERRORLOG, erreur 18456). Chez nous, il s’agissait entre autres d’une ancienne application web inutilisée sur le serveur.
Dans Optima 2026.5, le service d’opérations automatiques ne fonctionne pas sous le compte LocalSystem. Il lui faut un compte Windows dédié, et le fichier du mot de passe doit se trouver dans le profil de ce compte.
Nous ne communiquons pas le mot de passe CDNOperator à des personnes extérieures. Ce login a généralement accès aux bases de toutes les sociétés dans Optima.
Pour les postes connectés à la base via VPN ou Wi-Fi, le délai réseau s’ajoute à chacune des nombreuses connexions d’Optima. C’est pourquoi nous recommandons de travailler via le bureau à distance sur le serveur.

Vérification de l’indicateur après une mise à jour :

DBCC TRACESTATUS(4671);

Sources

Nous pouvons le faire pour vous

Si Optima a ralenti après une mise à jour de SQL Server, nous trouverons la cause et ferons la modification avec une sauvegarde et un plan de retour. En savoir plus sur notre informatique pour cabinets comptables. Écrivez à kontakt@proop.pl ou appelez le +48 690 504 074.