Comment nous avons ramené un démarrage de plus de six minutes à dix secondes, sans changer une seule machine.

Si vous cherchez ce sujet, vous connaissez déjà la scène. L’utilisateur double-clique sur Batigest à 8 h 30. La fenêtre n’apparaît pas. Il relance, parce que c’est ce qu’on fait. Toujours rien. À 8 h 37 l’écran de connexion s’affiche enfin, et à la première ouverture de la liste des devis, une erreur de chargement. Seul remède connu : redémarrer le poste. Le lendemain, tout va bien. Le surlendemain, rebelote.

La réponse qu’on reçoit généralement, c’est que le poste ne respecte pas les préconisations matérielles. Nous avons entendu la même chose. Sauf que les mêmes machines, sans le moindre changement de matériel, démarrent aujourd’hui Batigest en une dizaine de secondes, écran des devis compris. Le problème n’était pas la puissance. Il était dans la façon dont Windows partage le dossier de données.

Voici ce que nous avons trouvé, et comment le vérifier chez vous.

Le décor

Un parc typique de PME du bâtiment : trois postes sous Windows 11 Pro en groupe de travail, pas de serveur dédié. Le poste principal héberge SQL Server Express et publie le dossier C:\Sage en partage réseau. Les deux autres postes ouvrent Batigest Connect 9.1 à travers ce partage. Réseau gigabit filaire, tout ce qu’il y a de plus banal.

Détail qui oriente tout le diagnostic : sur le poste principal, Batigest démarre normalement. Sur les postes clients, il rame ou ne démarre pas. La seule différence entre les deux situations, c’est le passage par le réseau.

Ce que la mesure a montré

Nous avons capturé le trafic réseau des deux côtés simultanément, puis décodé les échanges SMB trame par trame. La séquence est toujours la même.

Batigest travaille sur un moteur de fichiers qui enchaîne des rafales d’ouvertures et de fermetures sur le dossier partagé, des centaines d’opérations pour une seule action à l’écran. Pour éviter d’aller chercher chaque information sur le réseau, Windows accorde au poste client des verrous opportunistes : « garde cette information en mémoire, je te préviendrai si quelqu’un d’autre y touche ».

Le problème surgit à l’énumération suivante. Le serveur doit alors révoquer un verrou que le poste client détient lui-même. La notification de révocation part du serveur, arrive sur la carte réseau du client… et n’est jamais acquittée. Le serveur la retente 35 secondes plus tard, en vain. Pendant ce temps l’énumération reste sans réponse, et au bout de 60 secondes le client tue purement et simplement la session réseau.

C’est exactement ce que vit l’utilisateur : une application figée, une erreur de chargement après une trentaine de secondes, et le redémarrage du poste comme unique solution… puisque redémarrer, c’est repartir d’une session propre et de caches vides.

Le test qui coûte deux minutes

Avant toute chose, vérifiez que c’est bien votre cas. Sur un poste qui vient de ramer, ouvrez l’Observateur d’événements et allez dans :

Journaux des applications et des services > Microsoft > Windows > SMBClient > Connectivity

Cherchez les événements 30809 et 30823. S’ils apparaissent aux heures de blocage, vous avez le même problème que nous. S’ils sont absents, la suite de cet article ne vous concerne probablement pas, et vous venez d’économiser une soirée.

Les corrections

Tout se passe sur le poste qui héberge le partage. Rien à installer, rien à acheter, et tout est réversible.

Set-SmbServerConfiguration -EnableOplocks $false
Get-SmbShare Sage | Set-SmbShare -FolderEnumerationMode Unrestricted -CachingMode None -LeasingMode None
net config server /autodisconnect:-1

Ligne par ligne, ce que ça fait :

Les verrous opportunistes sont désactivés. On perd en théorie un peu de cache, on gagne l’absence de blocage. Sur un moteur de fichiers de ce type, l’échange est très largement gagnant.

L’énumération basée sur l’accès est coupée. Activée, elle fait vérifier les droits fichier par fichier à chaque listage de dossier, pour n’afficher que ce que l’utilisateur a le droit de voir. Sur un partage où tout le monde a les mêmes droits, c’est du travail pur perdu, multiplié par le nombre de fichiers.

Le cache hors connexion est désactivé. C’est la préconisation standard pour un partage de données de ce type. Nous voyions distinctement, dans les traces côté client, les sondes du mécanisme de fichiers hors connexion venir s’intercaler dans chaque opération.

La déconnexion des sessions inactives est supprimée. Par défaut, Windows coupe une session au bout de 15 minutes d’inactivité. Un utilisateur qui revient de réunion paie une reconnexion complète, au pire moment.

Sur ce seul lot de réglages, nous avons mesuré un lancement passé de 6 min 40 à 26 secondes.

Un mot sur ce qu’il ne faut pas faire : on trouve partout des recommandations de désactiver aussi tous les caches côté client durées de cache à zéro, verrous opportunistes désactivés sur les postes. Nous les avons appliquées, mesurées, puis remises aux valeurs par défaut. Une fois le serveur corrigé, elles n’apportaient rien et dégradaient les postes pour d’autres usages.

Le point de terminaison qui fait perdre vingt secondes

Autre découverte, indépendante : à chaque démarrage, l’application tente de joindre un point de terminaison des services connectés de l’éditeur. Quand celui-ci ne répond pas, chaque tentative coûte une vingtaine de secondes d’attente avant abandon.

En attendant un correctif éditeur, une ligne dans le fichier hosts coupe court immédiatement :

0.0.0.0 connect.sage.fr

Nous avons retenu 0.0.0.0 et non 127.0.0.1 : Windows retente trois fois une connexion refusée sur la boucle locale, ce qui réintroduit une partie du délai qu’on cherche à supprimer.

Si vous venez de changer de serveur

Trois résidus de migration nous ont coûté cher, et ils sont fréquents.

Un lecteur réseau mappé pointant vers un partage devenu inaccessible ajoute 30 à 65 secondes de délai d’expiration à chaque lancement. Vérifiez les mappages, y compris ceux que plus personne n’utilise.

Le fichier de configuration du dossier, PROJET.INI.TXT, peut encore porter le nom de l’ancienne machine dans le champ ComputerName. Comme ce fichier se trouve dans le dossier partagé, tous les postes clients lisent la même erreur et désignent un serveur décommissionné comme poste principal.

Enfin, l’horloge système. Un poste désynchronisé fait échouer les certificats et les jetons horodatés de l’application, qui réessaie alors en boucle sans jamais aboutir. Nous avons vu un poste avec près de treize heures d’avance : l’application tournait dans le vide, sans ouvrir la moindre connexion vers la base. Dix secondes après la remise à l’heure, tout repartait.

Les faux coupables

Pour vous éviter les impasses que nous avons explorées : l’antivirus n’était pas en cause, le composant d’affichage se créait en 11 millisecondes quand on le sollicitait directement, les composants système de l’application étaient rigoureusement identiques entre le serveur et les postes, la base de données répondait en 100 millisecondes, et le matériel n’a jamais été le facteur limitant. Onze hypothèses éliminées, mesures à l’appui, avant d’arriver au bon endroit.

Si vous constatez une montée du processeur sur le service SQL pendant les ralentissements, regardez bien si elle précède ou suit le blocage. Dans notre cas, l’activité anormale était une conséquence de requêtes reprises, jamais la cause.

Le résultat

De plus de six minutes et certains jours, aucun démarrage du tout à une dizaine de secondes jusqu’à l’écran des devis, connexion comprise. Sur le même matériel, le même réseau et la même version du logiciel.

Si vous reconnaissez vos symptômes et que les événements 30809 et 30823 apparaissent dans vos journaux, vous savez désormais par où commencer.

Cet article est un retour d’expérience d’Everense. L’analyse a été menée sur un parc en production, captures réseau et mesures à l’appui onze hypothèses écartées avant d’arriver à la bonne. Si vos postes présentent ces symptômes, demandez votre consultation gratuite sur everense.com/contact. Nous commençons toujours par mesurer avant de conclure.