Discussion :

[MarcelG]

Bonjour les amis,

Je développe actuellement un navigateur Excel permettant au collègue utilisateur d'accéder à plusieurs applicatifs.

Question:

Afin de rendre son utilisation obligatoire, comment savoir si un fichier applicatif a été ouvert depuis ce navigateur.

Certes, l'on peut boucler sur les fichiers de la session mais rien ne dit alors que c'est le navigateur qui a généré l'ouverture de l'applicatif.

Par avance, merci pour vos brillantes lumières.

Bonne journée à tous.

[Pierre Fauconnier]

Salut Marcel,

Il faudrait voir ce que tu entends pas applicatif... Un autre classeur Excel? une autre application qu'Excel?


Perso, n'étant pas adepte du pistage de l'utilisateur je me fous qu'il arrive sur un "applicatif" par un chemin plutôt que par un autre, du moment que le travail est fait... Et je ne vois pas bien comment on pourrait interdire l'accès à un "applicatif" si on n'y vient pas par le "bon" chemin.

[Jean-Philippe André]

Salut,

Il y a toujours des solutions techniques possibles, mais je rejoins Pierre sur la pertinence de ce besoin.

Parmi les solutions (plus ou moins complexes)
- création d'un fichier/detection du fichier
- passage de parametres
- lancement depuis ton navigateur A du formulaire principal du fichier B...

[Pierre Fauconnier]

Salut JP,

S'il s'agit de gérer des "applicatifs" sous forme de fichiers Excel, le passage de paramètres pourrait être une solution, mais cela nécessite de mettre du vba sur chaque fichier cible pour tester qu'il a reçu tel paramètre lors de son ouverture et le fermer fissa si ce n'est pas le cas.


Tout ça pour ça? Un peu l'art de se compliquer la vie et de faire ch*** son mode, à mon avis.

[Jean-Philippe André]

Je donne des idées, je ne cherche pas à savoir si le besoin est de type bazooka pour tuer un moucheron

Les solutions les plus simples sont souvent les meilleures, mais parfois ne pas chercher le blocage c'est le mieux, car en voulant complexifier, tu commences à vouloir tout contrôler et blinder... Ca vaut le coup ?

[Pierre Fauconnier]

Je sais JP. Ma réponse ne t'était pas personnellement adressée

Je complétais ton info sur les paramètres pour signaler que la solution par paramètre à l'ouverture passerait selon moi par un "piégeage" lors de l'ouverture du fichier, avec donc l'obligation de modifier toutes les cibles pour y placer le piège. Chacun fait ce qu'il veut de son temps, bien entendu. Si Marcel a "du temps à perdre"...

Une autre idée, mais il faut qu'Excel ne plante pas! Un xlam qui pilote l'application Excel (placé dans le xlstart). Il contient un tableau des fichiers à verrouiller avec deux colonnes (nom du fichier - Flag d'appel). Lors de l'ouverture d'un fichier, si son nom est dans le tableau, on regarde si le flag d'appel est à TRUE. Si pas, on ferme le fichier. Le flag se place au moment où l'on clique sur le lien dans "l'explorateur" et passe à False lors de la fermeture de la cible.

Un plantage d'Excel remettra la variable xlApp à nothing, de sorte qu'il faudrait que l'explorateur teste cette variable et la réveille si besoin. Jouable, mais lourd puisque la variable xlApp va devoir intercepter chaque ouverture/fermeture de fichier et traiter le cas s'il échet.

[MarcelG]

Bonjour Jean Philippe, Pierre,

Je ne voulais pas porter à polémique, bien entendu.

Je précise.

Le fichier appelant est un fichier Excel que j'ai appelé "Navigateur" sur lequel des boutons de commande ouvrent tel ou tel autre fichier Excel, que j'appellerai "applicatif".

Or ce navigateur active, à son ouverture, un fichier xlam tierce (régulièrement mis à jour).
Il comporte des fonctions qui sont utilisables au sein même de l'applicatif (exemple IsFileOpen...).
Il suffit juste alors d'activer la référence.

En schématisant:
Ouverture du navigateur Excel ==> chargement du dernier xlam mis à jour
Dans le navigateur Excel: boutons de commande qui actionnent l'ouverture d'un fichier Excel (applicatif)
Or ce dernier (comme tous les autres), dans son activité, utilise les fonctions du fichier .xlam ci-dessus.

C'est la raison pour laquelle j'ai besoin de m'assurer que l'applicatif a bien été appelé depuis le navigateur.

Ce processus évite ainsi une redondance de fonctions, entre autres.
Je dis "entre autres" car, pour être presque exhaustif, la gestion de tous les profils de mon entité s'effectuent via le fichier .xlam.

Illustration
la fonction Is_Manager est gérée par le .xlam
Cette fonction ne figure pas dans l'applicatif.

J'ai testé.
En activant la référence, la fonction Is_Manager est effective au sein de toute procédure de l'applicatif.

J'espère avoir été clair.

Par ailleurs, vous me connaissez, ce n'est pas dans mon caractère d'ennuyer 100 collègues.

[Pierre Fauconnier]

J'espérais bien que tu n'allais pas épier 100 collègues

Pourquoi ne pas référencer le xlam dans chaque applicatif? Ainsi, à l'ouverture de l'applicatif, tu as tout dispo, non?

Si tu places le xlam dans le xlstart, il sera ouvert dès que tu ouvres Excel. Ca veut dire que si tu as des fonctions perso dedans, tu peux les utiliser dans tes applicatifs...

Je suis perplexe car j'ai l'impression de ne pas bien comprendre ton problème.

[MarcelG]

Si tu places le xlam dans le xlstart, il sera ouvert dès que tu ouvres Excel. Ca veut dire que si tu as des fonctions perso dedans, tu peux les utiliser dans tes applicatifs...

Si j'ai bien compris, il faudrait que j'intervienne sur 100 postes pour modifier cette option



Or ma configuration (100 postes sur 2 sites à Paris + 2 sites en Province); d'après moi, ne le permettrait pas.

Pourquoi ne pas référencer le xlam dans chaque applicatif? Ainsi, à l'ouverture de l'applicatif, tu as tout dispo, non?

J'y ai pensé.
Je vais creuser dans ce sens et ne manquerai pas de revenir.

[Pierre Fauconnier]

Placer ton xlam dans le xlstart, c'est le mettre à disposition de tout classeur qui en a besoin. Ca pourrait être réalisé par un "installeur" qui retrouverait le chemin du xlstart et y déposerait le fichier. Chez plusieurs de mes clients, des xlam sont placés ainsi pour aller chercher des infos dans le logiciel de compta. Ca fonctionne pas trop mal. De toutes façons, pour contrôler que tu es passé par l'explorateur pour ouvrir le fichier, il faudra que le xlam soit placé dans le xlstart pour être activé dès l'ouverture d'Excel de façon à contrôler que les fichiers qui s'ouvrent doivent être pilotés par le lanceur/explorateur. Le xlstart a été créé expressément à ces fins, et je ne vois pas trop comment contourner cela.

Mais je reviens sur la question de la référence. Si, dans le projet vba de tes "applicatifs", tu as mentionné ton xlam, tu es sûr qu'il est disponible et dès lors, pourquoi passer par un explorateur Excel? Ce n'est toujours pas clair pour moi.

[MarcelG]

Placer ton xlam dans le xlstart, c'est le mettre à disposition de tout classeur qui en a besoin. Ca pourrait être réalisé par un "installeur" qui retrouverait le chemin du xlstart et y déposerait le fichier. Chez plusieurs de mes clients, des xlam sont placés ainsi pour aller chercher des infos dans le logiciel de compta. Ca fonctionne pas trop mal. De toutes façons, pour contrôler que tu es passé par l'explorateur pour ouvrir le fichier, il faudra que le xlam soit placé dans le xlstart pour être activé dès l'ouverture d'Excel de façon à contrôler que les fichiers qui s'ouvrent doivent être pilotés par le lanceur/explorateur. Le xlstart a été créé expressément à ces fins, et je ne vois pas trop comment contourner cela.

Je ne connaissais pas cette notion de xlstart Je vais creuser.
Mais d'ores et déjà, je ne vois pas ce que tu entends par

Ca pourrait être réalisé par un "installeur" qui retrouverait le chemin du xlstart et y déposerait le fichier.

Mais je reviens sur la question de la référence. Si, dans le projet vba de tes "applicatifs", tu as mentionné ton xlam, tu es sûr qu'il est disponible et dès lors, pourquoi passer par un explorateur Excel? Ce n'est toujours pas clair pour moi.

Ce que tu appelle "Explorateur Excel", et moi "Navigateur", trouve sa nécessité dans le fait que, pour des questions d'organisation, mes applicatifs sont disséminés sur nombre de ressources (répertoires).
Ainsi, les utilisateurs ont du mal à s'y retrouver.
Un navigateur empêche la recherche de tel ou tel emplacement pour tel ou tel applicatif.
Mon but est de leur simplifier la tache.

Cela dit, il est souvent ardu d'exposer ses contraintes professionnelles qui amènent à envisager telle ou telle solution.
La confidentialité, d'abord, puis les cas de figures qui peuvent se présenter dans leur multitude.
Ensuite, les contraintes administratives. Qui peut faire quoi sur quelle ressource?
Enfin les contraintes techniques. Il faut savoir, en effet, que certaines options d'Excel peuvent être "blindées".

Dans ces conditions, nous n'avons pas d'autre choix que de "faire avec".
Ceci au risque d'exprimer une problématique susceptible de paraître "étrange", ce qui est, somme toute, légitime.

[Pierre Fauconnier]

Pour le xlstart: Tout fichier Excel présent dans le xlstart est ouvert à l'ouverture d'Excel. C'est d'ailleurs là qu'est placé le PERSONAL.XLSB qui est créé lorsque tu crées une macro et que tu la places dans le classeur de macros personnelles.



Si tu dois "faire" installer ton xlam sur les postes de tes collaborateurs, tu peux leur envoyer le xlam avec un script vbs ou un fichier Excel qui copiera le fichier xlam au bon endroit. C'est ce fichier que j'appelle un "installeur"


Pour le reste, je comprends bien les contraintes techniques, administratives et autres, mais je persiste et signe. Sans un xlam dans le xlstart, tu ne pourras contrôler que le fichier est bien ouvert par ton navigateur qu'en mettant du code dans ledit fichier puisque, potentiellement, tout fichier Excel qu'un utilisateur peut atteindre avec la souris est "ouvrable". C'est la solution "paramètres" évoquée par Jean-Philippe.

Le xlam dans le xlstart permet de contrôler l'application Excel elle-même et de capturer les évènements d'ouverture ou de fermeture de fichiers Excel.



Tu peux alors gérer les évènements relatifs aux workbooks.



L'idée est alors la suivante:

• Au clic sur un fichier x dans le navigateur, celui-ci retrouve la ligne du fichier x dans un tableau structuré du xlam, et y place un flag "OK" puis ouvre ledit fichier;
• l'évènement illustré ci-dessus s'enclenche, et le xlam regarde l'état du flag dans le tableau: Ok => il laisse passer; NOK, il ferme et informe l'utilisateur;
• A la fermeture dudit fichier, l'évènement workbook_Close est levé et le xlam modifie le OK en NOK;
• Si on ouvre le fichier sans passer par le navigateur, le xlam trouvera NOK et bloquera;
• Tout fichier non présent dans le tableau du xlam est réputé ouvrable sans le navigateur;
• La variable xlapp étant une propriété publique du xlam, le navigateur peut l'atteindre pour la "réveiller" au cas où elle aurait été tuée par un plantage de code.

[MarcelG]

Bonsoir le Forum, Bonsoir Pierre,

Voilà qui est constructif et dont je te remercie.

J'ai suivi ta démarche. (ou du moins essayé de la suivre)

Si je place cette déclaration dans l'évènement Open, l'évènement n'est pas effectif.

Après recherches, j'ai tenté l'instanciation d'un module de classe.
Dans ce cas, le processus est bien effectif
(Dans cette phase de tests, et d'apprentissage, je me suis contenté d'une cellule test
Je déploierai ensuite la gestion de tous les applicatifs à partir d'un tableau structuré)

Dans le classeur xlam

1 - Module de classe Lappli_Excel

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Option Explicit
 
Public WithEvents App As Excel.Application
 
Private Sub App_WorkbookOpen(ByVal Wb As Workbook)
 
With Wb
        If InStr(.Name, "lemachin") > 0 Then
                If Sht_Collaborateurs.Range("test_navig").Value = "KO" Then
                                MsgBox _
                                        Prompt:="Veuillez utiliser le navigateur.", _
                                        Buttons:=vbCritical, _
                                        Title:="Utilisation erronée"
                        Application.EnableEvents = False
                        .Close Savechanges:=False
                        Application.EnableEvents = True
                End If
        End If
End With
 
End Sub
 
Private Sub App_WorkbookBeforeClose(ByVal Wb As Workbook, Cancel As Boolean)
    Sht_Collaborateurs.Range("test_navig").Value = "KO"
    Call affichage_normal
End Sub

2 - Evènement Open

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
Option Explicit
 
Dim myexcel As New Lappli_Excel
 
Private Sub Workbook_Open()
Set myexcel.App = Excel.Application
End Sub

Et dans le navigateur

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Private Sub Btn_Lemachin_Click()
'nom_long_xlam = fonction
Workbooks(nom_long_xlam).Worksheets("Collaborateurs").Range("test_navig").Value = "OK"
'procédure argumentée
Call Ouvrir_logiciel("lerép\lemachin_V13.xlsm")
End Sub

Si le fichier est ouvert par le navigateur: OK
Dans le cas contraire, KO avec message "Utiliser le navigateur" et fermeture du fichier.

J'ai procédé à plusieurs test qui se sont révélés, à priori, positifs.

Maintenant, en ce qui concerne la mise à jour du fichier xlam.
(En effet, les versions d'applicatifs peuvent évoluer, les collaborateurs peuvent partir, arriver, changer de fonction)
Voici le processus que j'envisagerais, peut-être à partir du navigateur

1. Fermeture du fichier xlam
2. Destruction
3. Copie

depuis une ressource commune à tous (J'en ai trouvée une)
dans le répertoire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

XLSTART  = "C:\Users\" & Environ("Username") & "\AppData\Roaming\Microsoft\Excel\XLSTART

Au préalable, j'aurais enregistré mon utilitaire de base .xlsm en .xlam sur cette ressource commune
(propriété IsAddin = True et FileFormat:=xlOpenXMLAddIn)

C'est ce que je pense et te soumets.

[Pierre Fauconnier]

[...]
Maintenant, en ce qui concerne la mise à jour du fichier xlam.
(En effet, les versions d'applicatifs peuvent évoluer, les collaborateurs peuvent partir, arriver, changer de fonction)
Voici le processus que j'envisagerais, peut-être à partir du navigateur

1. Fermeture du fichier xlam
2. Destruction
3. Copie

[...]

Tu ne peux pas le faire comme ça. Le xlam étant dans le xlstart, il est ouvert à l'ouverture de l'instance Excel => ton navigateur (fichier Excel) ne pourra donc le détruire puisqu'il sera forcément ouvert si ton navigateur l'est. Pour vraiment remplacer le fichier, il faudra un vbs ou un powershell qui teste que le fichier est fermé pour pouvoir le supprimer et le remplacer par la nouvelle version.

Cela étant dit, normalement, lorsque la mécanique de ce xlam est au point (et il n'y a rien de bien complexe, en fait), tu ne devrais pas devoir toucher à sa structure, ni côté Excel ni côté VBA, de sorte que ce sont simplement ses tableaux (son tableau dans une version simple mais fonctionnelle) qui doivent être mis à jour. Dès lors, le navigateur pourrait s'en charger. Tu fournis un navigateur avec un tableau similaire à celui du xlam contenant la liste des fichiers mise à jour, puis à l'ouverture du navigateur, tu vidanges le tableau du xlam et tu lui transfères celui du navigateur. Tu mets un flag de mise à jour dans le navigateur pour ne réaliser l'opération qu'une seule fois et le tour est joué.

[MarcelG]

D'accord Pierre,

Dans un 1er temps je vais généraliser la gestion de tous les applicatifs.

Dans un 2ème, je vais essayer de suivre ton processus.

Au passage, il est bien, du moins dans mon environnement, de généraliser l'adresse du fichier XLSTART à l'aide de l'identifiant (Environ("Username")

Une semaine, et je reviendrai sans doute.

Bon week-end à toi, bon week-end au forum.

[MarcelG]

Bonjour à tous,

Les développements de ces processus ont été mis en production, au sein de mon entité, début Septembre.

Après quelques retours d'anomalie ("Marcel, çà ne marche pas sur mon poste"), j'ai attendu ce moment pour les livrer après un nombre d'utilisations conséquent.

Il faut dire que l'imagination des utilisateurs dépassent parfois l'imagination (Copie dans "Mes Documents", Quitter Excel par le gestionnaire des taches...)

Le contexte:
120 postes de travail situés sur des sites différents.
Chaque collaborateur, selon son profil (collaborateur, manager…) utilisent des applicatifs différents, placés sur des serveurs différents.

Ces applicatifs font appel à des fonctionnalités communes (pyramide commerciale, pyramide managériale, gestion écran…)

Pour des raisons de praticité, propres à notre environnement, et après plusieurs essais, j'ai du renoncer à l'utilisation du répertoire XLSTART
Je livre donc ici une démarche autre mais testée pendant les 3 derniers mois.

Processus:
Un utilitaire renferme toutes les tables de données communes et toutes les fonctions « typées » utilisées par les différents applicatifs
Ce fichier Excel, lors de son enregistrement, fait l’objet d’un autre enregistrement en Addin, cette fois, sur un serveur annexe
Un utilitaire Excel sert de portail d’entrée aux différents applicatifs (Navigateur)
A son ouverture, une procédure met à jour les Addins de l’utilisateur depuis le serveur annexe ci-dessus
Ce navigateur a pour Référence l’Addins utilitaire.

A son ouverture:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Private Sub Workbook_Open()
'Module "Gestion_Addins"
Call Delete_réf_broken
'Module "Gestion_Addins"
Call vide_dossiers_microsoft
'Module "Gestion_Addins"
 Call gest_addin
End Sub

La procédure Delete_réf_broken a pour fonctionnalité de supprimer les références « manquantes » éventuelles
La procédure vide_dossier_microsoft a pour fonctionnalité de vider le dossier « Addins » de l’utilisateur (éventuellement celui des récupérations automatiques)
La procédure gest_addins a pour fonctionnalités successives :
- Désactiver et désinstaller les anciennes macros complémentaires
- La mise à jour de l'Addin: copie depuis le serveur vers le répertoire Addins du collaborateur
- L’activation et l’installation des nouvelles macros complémentaires

L’ensemble des procédures est reporté dans le fichier joint à ce post

L’intérêt de ce processus
1 - Avant sa mise en place, les mêmes fonctionnalités affectaient les applicatifs.
Si l’une d’elles venait à évoluer, alors il me fallait modifier tous les applicatifs
Dorénavant, une seule modification est nécessaire au sein du classeur initial devenu addin après son enregistrement
Exemple : Nom du Directeur des Ventes de tel Inspecteur
2 - Les collaborateurs ne disposent sur leur bureau que d’un seul raccourci, celui du navigateur. Ce raccourci étant, par ailleurs créé lors de la première activation

Ce sont les raisons pour lesquelles l’ouverture du navigateur est obligatoire afin de permettre l’activation de l’addin.
Le classeur antécédent qui deviendra addin est affecté d’une instanciation de classe à son ouverture.

Une réserve.
Lors du 1er emploi de tel ou tel applicatif, un "plantage" survenait automatiquement.
Les fonctions appelées n'existant pas, et pour cause...
Il m'a fallu donc "communiquer".

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
Option Explicit
'https://www.developpez.net/forums/d2111612/logiciels/microsoft-office/excel/macros-vba-excel/tester-applicatif-ete-ouvert-classeur-defini/
 
Dim myexcel As New Lappli_Excel
 Private Sub Workbook_Open()
 
Set myexcel.App = Excel.Application
 
End Sub

Module de classe:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
Option Explicit
 
Public WithEvents App As Excel.Application
 
Private Sub App_WorkbookOpen(ByVal Wb As Workbook)
 
With Wb
        If vérif_navig(.Name) = False Then
                Application.EnableEvents = False
                .Close savechanges:=False
                Application.EnableEvents = True
                MsgBox _
                        Prompt:="Veuillez utiliser le navigateur.", _
                        Buttons:=vbCritical, _
                        Title:="Utilisation erronée"
        End If
End With
 
End Sub
 
 
Private Function vérif_navig(nom_appli As String) As Boolean
 
vérif_navig = False
 
Dim champ_vérif As Range
Set champ_vérif = ThisWorkbook.Worksheets("Applicatifs").Range("T_appli_court[appli_court]")
 
Dim lappli As Variant
 
Dim n As Byte
n = 0
 
Dim Is_in_liste As Boolean
Is_in_liste = False
 
Do Until (Is_in_liste = True) Or (n = champ_vérif.Count)
        n = n + 1
        'Debug.Print champ_vérif(n)
        'Debug.Print InStr(nom_appli, champ_vérif(n))
        Is_in_liste = (InStr(nom_appli, champ_vérif(n)) > 0)
Loop
 
'Si l'applicatif ouvert n'est pas dans la liste des applicatifs contrôlés
'alors il est inutile de savoir s'il a été ouvert par le navigateur
If Is_in_liste = False Then
        vérif_navig = True
Else
        vérif_navig = (Sht_Utilitaires.Range("test_navig").Value = "OK")
End If
 
Set champ_vérif = Nothing
 
End Function

Conclusion:
Après environ 1000 utilisations depuis 3 mois, ce navigateur semble stabilisé. Je n’ai plus aucun retour d’anomalie.
Qui plus est, les utilisateurs sont satisfaits.
Dès lors 2 questions :
Ai-je perdu mon temps ? Ai-je « ennuyé » mes clients collègues ?

[Pierre Fauconnier]

Salut Marcel,

La déclaration seule ne suffit pas. Tu dois "l'instancier" à l'ouverture du fichier



Je voulais poster un xlam hier soir mais je n'ai pas pris le temps...

[MarcelG]

C'est ce que j'ai fait, Pierre, dans un 1er temps.

J'ai effectué le test avec un simple message "Bonjour".
Résultat nul.

C'est pourquoi j'ai recherché une autre voie.

Par contre, la combinaison Module de Classe - Evènement Open, telle que je l'ai décrite, est bien effective.
J'ai testé. Le code fonctionne bien.

(Je n'ai plus en tête le site)

[Pierre Fauconnier]

N'étant pas dans ton dos pour voir ce que tu as fait, je ne saurais pas dire ce qui a posé problème, mais la solution que je propose est effective et fonctionne parfaitement.

Il faut toutefois noter que si tu arrêtes le code, à la suite d'un débogage par exemple, la propriété publique meurt et donc, tu dois l'instancier à nouveau. Mais tu auras le même problème avec un objet de classe perso. C'est pour cela qu'il faut blinder son code avec des On Error. Normalement, un xlam ne peut pas planter sinon forcément, ça fout le système par terre.

[MarcelG]

Au temps pour moi.

Tu as raison

Ce code est bien effectif

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Option Explicit
 
Public WithEvents App As Excel.Application
 
Private Sub Workbook_Open()
Set App = Excel.Application
End Sub
 
Private Sub App_WorkbookOpen(ByVal Wb As Workbook)
 
With Wb
        If InStr(.Name, "Lemachin") > 0 Then
                If Sht_Collaborateurs.Range("test_navig").Value = "KO" Then
                                MsgBox _
                                        Prompt:="Veuillez utiliser le navigateur.", _
                                        Buttons:=vbCritical, _
                                        Title:="Utilisation erronée"
                        Application.EnableEvents = False
                        .Close Savechanges:=False
                        Application.EnableEvents = True
                End If
        End If
End With
 
End Sub
 
Private Sub App_WorkbookBeforeClose(ByVal Wb As Workbook, Cancel As Boolean)
    Sht_Collaborateurs.Range("test_navig").Value = "KO"
    Call affichage_normal
End Sub

Bien pris en compte ta remarque.

En ce qui concerne la mise à jour du xlam, ton avis?