1. Code licence

1.1. Description

Dans une une installation locale, le code licence est enregistré dans la configuration de l’utilisateur Windows lors du premier démarrage de l’application. Par la suite, ce code licence est retrouvé et sert pour l’identification de l’utilisateur sur nos serveurs.


Dans l’environnement terminal serveur, le code licence de l’application peut être enregistré avec la configuration de l’application, et ainsi directement disponible aux utilisateurs. Cette possibilité existe aussi pour une installation locale, où l’intérêt est mineur, mais pour une installation en TS, l’administrateur peut enregistrer ce code licence pour tous les clients du système. Le contrôle complet de l’application peut ainsi être donné à un administrateur système. Ce contrôle est doté également d’un paramètre de contrôle qui, s’il est mis (confer plus loin), ne permet pas à l’utilisateur de démarrer l’application si cet administrateur n’a pas enregistré un code licence valide.


Un module d’administration (décrit plus loin) permet d’introduire ce code licence dans la configuration, ainsi que de régler le paramètre de contrôle.

1.2. Module d’administration

Il s’agit d’un module du panneau de configuration, accessible uniquement si l’utilisateur a les droits d’administrateur. Ce module présente entre autre un onglet de gestion des licences :

  • Une sélection « Gestion par chaque utilisateur » versus « Gestion centralisée » ; la sélection par défaut est celle qui prévaut pour une utilisation locale

  • Une zone d’édition du code licence : affiche par défaut le code licence éventuellement déjà enregistré. Cette zone d’édition n’est disponique que la « Gestion centralisée » est sélectionnée

  • Une case à cocher « Arrêt de l’application en l’absence de code licence » :

A noter que la case à cocher n’a un effet que si elle est cochée ET si aucun code licence n’est enregistré dans la configuration centralisée


1.3. Exemples d’utilisation

1.3.1. PC local, administré par quelqu’un d’autre que l’utilisateur final

Situation: il s’agit par exemple du PC d’un comptable ou d’une secrétaire, mais c’est une autre personne qui gère le PC, qui fait les installations de logiciels et les mises à jour, et qui gère les licences des logiciels.

  • Après installation du logiciel, l’administrateur introduit le code licence dans la configuration au moyen de l’outil d’administration décrit ci-dessous

  • Il laisse la case à cocher décochée ; il peut la cocher : c’est sans incidence dès qu’un code licence est introduit

  • Avantage : d’un point de vue administratif, l’application est immédiatement prête à l’emploi, l’utilisateur final n’ayant plus à se soucier du code licence

1.3.2. TS interne dans une société

Situation : Le TS est interne à la société, tous les clients de ce TS ont accès (ou peuvent avoir accès) aux mêmes applications. Le TS est géré par un administrateur, et les clients n’ont pas de droits d’administrateur

  • Après installation du logiciel, l’administrateur introduit le code licence dans la configuration au moyen de l’outil d’administration décrit ci-dessous

  • Il laisse la case à cocher décochée ; il peut la cocher : c’est sans incidence dès qu’un code licence est introduit

  • Avantage : d’un point de vue administratif, l’application est immédiatement prête à l’emploi, les clients du TS ont directement accès à l’application (pour autant qu’ils aient accès au répertoire où l’application est installée, et éventuellement que l’administrateur aie installé un raccourci dans leur bureau : confer plus loin).

  • Attention : avec cette approche, tous les utilisateurs sans exception peuvent démarrer l’application (pour autant qu’ils aient accès au répertoire où celle-ci est installée, bien entendu). Si cet accès doit être limité à une certaine catégorie d’utilisateurs, il faut :
    • soit bloquer les autres utilisateurs via la configuration de la base de données (confer plus loin : configurer la localisation de la base de données dans la configuration de l’application et ne pas autoriser l’utilisateur a en sélectionner une autre si elle n’est pas accessible),

    • soit adopter l’approche décrite ci-dessous pour les TS partagés, avec la case à cocher cochée.

1.3.3. TS partagé, plusieurs utilisateurs ou sociétés indépendantes travaillent sur le même TS

Situation : le TS est externe, et plusieurs entités indépendantes l’utilisent. Un administrateur gère le TS, et attribue les droits nécessaires aux différents utilisateurs ou aux différents groupes d’utilisateurs.

  • Après installation du logiciel, l’administrateur n’introduit pas de code licence dans la configuration de l’application
  • Dans la situation actuelle de l’application, chaque utilisateur doit introduire le code licence, comme pour une installation locale : il n’y a pas encore de gestion centralisée.
  • Une gestion centralisée est prévue, mais pas encore disponible actuellement.

2. Localisation DB

2.1. Description

Dans une installation locale, le chem in vers la base de données est déterm iné une fois pour toute lors du tout premier démarrage de l’application.


Comme pour le code licence, le chemin vers la base de données peut être enregistré dans la configuration de l’application. A nouveau, pour une installation locale, l’in térêt est m ineur, mais pour une installation en TS , l’adm inistrateur peut enregistre r ce chemin pour tous les clients du système. Il faut évidemment que ce chem in soit interprétable de la m ême m anière par tous les utilisateurs : en par ticulier que le m apping soit cohérent ! Un param ètre de contrôle perm et également de contrôler le déroulement du processus.


Le déroulement du démarrage de l’application est alors le suivant :

  • Elle consulte cette configuration:
  • Soit un chemin (configuré par l’administrateur système) est trouvé :
    • Si l’utilisateur n’a pas les droits requis sur ce répertoire, un message d’avertissement apparait et l’application s’arrête
    • Si ce répertoire n’existe pas ou n’est pas accessible : suivant le paramètre de contrôle mentionné ci-dessus, soit l’application s’a rrête, soit elle conti nue en perm ettant à l’utilisateur de créer une base de données locale
  • Soit aucun chemin n’est trouvé:
    • Le déroulement est alors identique à une in stallation standard, où l’utilisateur peut sélectionner lib rement l’em placement de la base de donn ées, et créer celle-ci si nécessaire.

2.2. Module d’administration

Il s’agit du même module du panneau de configuration évoqué pour le code licence, visible et donc accessible uniquement si l’utilisateur a les d roits d’administrateur. Ce module présente entre autre un onglet de gestion des bases de données :


  • Une sélection « Gestion par chaque utilisateur » versus « Gestion centralisée » ; la sélection par défaut est celle qui prévaut pour une utilisation locale
  • Une zone d’édition pour le nom    du répertoire   logique où créer et    gérer les données de l’application, avec un bouton pour naviguer ve    rs ce répertoire : attention, ce bouton de navigation permet d’atteindre un répertoire phys ique, mais c’est bien un répertoire logique qui doit être introduit    !!!!    Cette zone d’édition n’est    disponique que la «    Gestion centralisée » est sélectionnée
  • Une case à cocher « Arrêt de l’application en l’absence de DB configurée » 
    • Cette case à cocher ajuste le bit 1 du paramètre HKLM\...\Configuration :TSMode

A noter que la case à cocher n ’a un effet que si elle est cochée ET si un chem in vers la DB est configuré ici de manière centralisée.


2.3. Exemples d’utilisation

2.3.1.    PC local, administré par quelqu’un d’autre que l’utilisateur final

Situation : il s’agit par exem ple du PC d’un comp table ou d’une secrétaire , m ais c’est une autre personne qui gère le PC, qui fait les installations de logiciels et les mises à jour, et qui gère les bases de données.


  • Après installation du lo giciel, l’ad ministrateur introdu it le chem in vers la DB dans le module d’administration décrit ci-dessus (il n’y a pas de différe nce entre chem in logique et chemin physique, puisqu’un seul utilisateur est concerné) e
  • la Iclalsaeisàs cocher décochée
  • Avantage : d’un point de vue a dministratif, l’app lication est imm édiatement prê te à l’emploi, l’utilisateur final n’ayant plus à se soucier de la base de données, pour autant que le chemin défini soit accessible
  • il Oopcthieon la case à co  cher.  S’il n’a pa    s de droits d’adm inistrateur, l’utilisateur n’a alors plus la possibilité de changer de DB sans le support de l’administrateur du PC.


2.3.2. TS interne dans une société

Situation: Le TS est interne à la société, tous les clients de ce TS ont accès (ou peuvent avoir accès) aux mêmes applications. Le TS est géré par un administrateur, et les clients n’ont pas de droits d’administrateur:


  • Prérequis : l’adm  inistrateur m  appe pour ch    aque utilisateur ou    pour chaque groupe d’utilisateurs un lecteur vers un répertoire qui est le m ême pour tous les utilisateurs ou pour tous les gro upes qui doivent utilise r l’application. Les utilisateur s doivent avoir les droits d’écriture sur ce disque, ou en t   out cas sur le répertoire qui    sera désigné pour contenir la base de données.
  • Après installation du logiciel, l’ administrateur introduit le chemin logique vers la DB da ns l’outil d’adm inistration décrit ci-dessous ; ce chemin doit être identique pour tous les utilisateurs.
  • Il coche la case à cocher : ainsi si le serveur de données est non disponible (celui-ci peut être différent du TS), l’utilisateur n’est pas inv ité à séle ctionner une au tre loca lisation, avec toutes les conséquences que cela pourrait avoir.
  • Avantage : d’un point de vue a dministratif, l’app lication est imm édiatement prê te à l’emploi, les clients du TS ont directem ent ac cès à l’application (pou r autan t qu’ils aient accès au répertoire où l’applica tion est in stallée et au répert oire où les données doivent se trouver, et éventuellem ent que l’administrateur aie installé un raccourci dans leur bureau : confer plus loin).
  • Marquee : si certains utilisateurs ne doi    vent pas avoir accès aux données et donc à l’application, il suffit que le chemin vers ces données ne soit pas mappé pour eux, ou en tout cas qu’ils n’aient pas les droits d’écriture sur ce répertoire ; ils se retrouvent dans le cas de figure « chemin trouvé m ais non ac cessible et pa ramètre de contrôle m is » : l’application s’arrête


2.3.3. TS partagé, plusieurs utilisateurs ou sociétés indépendantes travaillent sur le même TS

Situation: le TS est externe, et plusieurs entités indépendantes l’utilisent. Un administrateur gère le TS, et attribue les droits nécessaires aux différents utilisateurs ou aux différents groupes d’utilisateurs.


  • Prérequis : l’adm  inistrateur m  appe pour ch    aque utilisateur ou    pour chaque groupe d’utilisateurs un lecteur vers un répertoire qui lui est propre. Exemple : le lecteur « U:\ » (la même lettre pour tous les utilisateurs) pointe ve rs un répertoire du serveur qui est différent pour chaque utilisateur. Alternativem ent, pour chaque grou pe d’utilis ateurs, il m appe un lecteur (par exem ple « G:\ ») vers un répertoire du serveur qui    est le m ême pour tous les utilisateurs du groupe, mais qui est différent pour les différents groupes.
  • Après installation du logiciel, l’ administrateur enregistre dans l’outil d’adm inistration le chemin logique (commun d’un point de vue s yntaxique) où trouver les données. Le premier utilisateur qui démarrera l’application créera la base de données vide.
  • Case à cocher:
    • Si la case à cocher pou r le code licence est cochée, cela signifie que l’ad ministrateur n’autorise pas l’accès à l’application pour les utilisateurs qui n’ont pas de licence : la configuration ici est sans intérêt puisque ces utilisateurs n’y arrivent pas
    • Si la case à cocher pour le code licence n’ est pas cochée, autorisant le mode démo pour les  utilis ateurs s ans licence  (ou autorisant la gestion de la licence par l’utilisateur lui-m ême) : l’at titude vis-à -vis de la case à cocher concernant la DB dépend de la situation:
      • L’utilisateur concerné à accès au chemin vers la DB qui est enregistré dans la configuration (chemin qui physiquement lui est propre, bien entendu) : il est alors conseillé de cocher la case à cocher. Ains i, en cas d ’absence d’accès (serveur de données non di sponible), l’utilisateur (avec licence ou non) n’est pas invité à sélectionner une autre localisation
      • L’utilisateur concerné n’a pas accès au ch emin vers la DB enregis tré dans la configuration (par exemple parce que ce chem in n’est pas créé physiquement pour lui  : la case à cocher ne doit pas être cochée, lui perm    ettant de sélectionner une base de données (localement ou ailleurs)


En résumé:

  • Utilisateurs avec code licence, gestion centrale par l’administrateur, pas d’autre utilisateur autorisé dans l’application :
    • Le code licence est enregistré dans un fichier propre à chaque utilisateur, et la case à cocher concernant le code licence est cochée (confer section précédente)

    • Définir le chemin vers les données, et l’enregistrer dans la clé « DBDir » : même chemin logique pour tous les utilisateurs (quel que soit le code licence), mais bien entendu chemins physiques différents pour les codes licence différents
  • Utilisateurs avec code licence, gestion centrale par l’administrateur, autres utilisateurs autorisés dans l’application (que ce soit en mode démo ou en gestion locale par l’utilisateur lui-même), données gérées par l’administrateur :
    • Le code licence est enregistré dans un fichier propre à chaque utilisateur, et la case à cocher concernant le code licence n’est pas cochée (confer section précédente)

    • Le chemin logique vers les données, défini pour les utilisateurs gérés de manière centrale, doit exister pour tous les utilisateurs (avec des chemins physiques différents) ; ce chemin est déjà enregistré dans la clé « DBDir » pour les utilisateurs gérés de manière centrale

    • La case à cocher concernant la DB est cochée ou non, c’est au choix. Il est conseillé de la cocher
  • Utilisateurs avec code licence, gestion centrale par l’administrateur, autres utilisateurs autorisés dans l’application (que ce soit en mode démo ou en gestion locale par l’utilisateur lui-même), données gérées par eux-mêmes :
    • Le code licence est enregistré dans un fichier propre à chaque utilisateur, et la case à cocher concernant le code licence n’est pas cochée (confer section précédente)

    • Le chemin logique vers les données, défini pour les utilisateurs gérés de manière centrale, ne doit pas exister physiquement pour les autres utilisateurs

    • La case à cocher concernant la DB ne doit pas être cochée

3. Sauvegardes de la DB

3.1. Situation normale (installation locale)

A priori, chaque utilisateur peut faire une sauvegarde de la DB, tant manuellement que automatiquement en fermant l’application.


Dans une installation en réseau, cela peut conduire à une gestion quelque peu anarchique, chacun pouvant faire une sauvegarde quand il le désire. Par ailleurs, cela peut conduire à une situation délicate, chacun pouvant penser qu’un autre fait des sauvegardes (évanescence des responsabilités).

Sur une installation en réseau, l’administrateur peut décider de se charger lui-même des sauvegardes, et surtout d’empêcher les utilisateurs d’en faire à tout moment.

S’il en décide ainsi, les fonctionnalités correspondantes disparaissent de l’application pour chaque utilisateur.


La manière d’exécuter les sauvegardes est laissée à son appréciation : on peut supposer que dans un environnement en réseau, des procédures de sauvegarde plus vastes sont déjà mises en place, et il n’est pas nécessaire d’en prévoir une supplémentaire ici.


3.2. Module d’administration

Il s’agit du même module du panneau de configuration évoqué ci-dessus, visible et donc accessible uniquement si l’utilisateur a les droits d’administrateur. Ce module présente entre autre un onglet de gestion des options


4. Adaptations de l’application

L’application présente un grand nombre de fonctionnalités, mais certaines n’ont guère de sens dans un environnement où l’utilisateur a des droits limités, et en particulier pour des clients sur un TS :


4.1. « Administration réseau » dans le menu « Fichier » de l’application

Cette fonctionnalité permet de transmettre à tous les postes connectés sur la même base de données les paramètres suivants

  • Paramètres proxy

  • Paramètres concernant les mises à jour (récurrence, etc)

  • Paramètres concernant certains documents (nombre de jours après lesquels une déclaration est obsolete et doit donc être introduite pour la période suivante, idem pour les listings, etc)

Dans un environnement TS, cette fonctionnalité n’a pas de sens. L’administrateur du TS (qui n’est probablement pas un utilisateur de l’application d’ailleurs) dispose de son propre outil pour ajuster certains de ces paramètres (proxy par exemple), et d’autres sont sans intérêt (mises à jour).


Le module d’administration permet de supprimer ces fonctionnalités de l’application.


4.2. « Sauvegarde intégrale de la DB » dans le menu « Fichier » de l’application

Cette fonctionnalité disparaît si l’administrateur a coché la case à cocher correspondante dans le module d’administration.


4.3. « Préférences » dans le menu « Fichier » de l’application

De même, l’onglet « Sauvegarde » dans les préférences disparaitrait si la case à cocher correspondante dans le module d’administration est cochée (confer point 5.3.1)


De la même manière, l’onglet « Internet » est adapté pour un client sur un TS : il ne peut pas faire de mise à jour, et peut même ne pas être averti de leur existence : voir module d’administration.


4.4. Module « Déconnexion base de données » dans le panneau de configuration

Si un chemin vers la DB est enregistré dans la configuration, et si l’utilisateur ne peut pas sélectionner une autre localisation lorsque ce chemin n’est pas accessible (confer section « Localisation DB » ci-dessus), ce module n’a plus de sens et disparaît.


4.5. Module « Restauration d’une sauvegarde » dans le panneau de configuration

Si l’utilisateur ne peut pas faire de base de données, il ne peut pas en restaurer non plus : ce module disparaît dans ce cas.


5. Mises à jour automatiques

Dans la situation habituelle, les mises à jour peuvent survenir de trois manières différentes :

  • Automatiquement, au démarrage de l’application, selon la configuration dans l’onglet « Internet » des préférences

  • Manuellement, par un click sur un bouton dans ce même onglet

  • Par importation, via un click sur un autre bouton dans ce même onglet (pour les postes off-line)

Dans les trois cas, la mise à jour est d’abord copiée dans un répertoire temporaire où l’utilisateur, quel qu’il soit, a les droits d’écriture

Ces mises à jour ne sont proposées ou possibles que si l’utilisateur a les droits d’administrateur (ancienne version de Windows), ou si un UAC est présent et activé (à partir de Vista). Si un UAC est détecté et actif, et si l’utilisateur n’a pas les droits d’administrateur, il est averti que ceux-ci lui seront réclamés au moment de la mise à jour effective.

Ensuite, à la fermeture de l’application, les droits d’administrateur sont éventuellement réclamés via l’UAC, et la mise à jour a effectivement lieu. L’application, ni aucun de ses outils, ne peut évidemment être exécuté pendant cette mise à jour (ils sont potentiellement concernés !).


Ce protocole, pratique sur un poste local (un seul utilisateur de l’application), ne convient pas sur un TS : en effet, même si un utilisateur ayant les droits nécessaire télécharge une mise à jour, ferme l’application et commence son installation, rien ne dit que l’application n’est pas en cours d’exécution sur un autre poste.


Un outil « CheckCDUpdate.exe » est proposé ; celui-ci exécute le protocole suivant :

  • Il vérifie si l’utilisateur courant a les droits d’administrateur : si ce n’est pas le cas, l’outil s’arrête immédiatement avec un message d’erreur ! Il faut les droits d’écriture sur le répertoire d’installation et dans la configuration de Windows.

  • Il vérifie la présence d’une mise à jour sur le serveur de Corporate copyright, et il vérifie si cette mise à jour est applicable, c’est-à-dire si elle est plus récente que la version installée sur le TS

  • Si une nouvelle mise à jour est disponible :
    • Il la télécharge dans un répertoire temporaire local (qui peut être défini dans le module d’administration)

    • Il vérifie qu’aucune instance de l’application n’est en cours d’exécution : si oui, réessaye toutes les minutes.

    • Dès que toutes les instances de l’application sont arrêtées, il actionne une clé dans la configuration de l’application : cette clé qui est consultée par l’application au démarrage permet de bloquer tout démarrage intempestif pendant l’exécution de la mise à jour

    • Il fait la mise à jour

    • Il vérifie l’intégrité de la mise à jour : en cas de problème, un rollback est exécuté (si possible)

    • Il désactive la clé dans la configuration : l’application peut à nouveau être utilisée

Cet outil, qui fait partie de l’installation, peut être exécuté à n’importe quel moment et peut également être enregistré dans un scheduleur pour exécution automatique, par exemple toutes les nuits.


L’outil est « bavard » : un message apparait à chaque stade de l’exécution pour indiquer la situation courante. La plupart de ces messages peuvent être supprimés via le module d’administration : seuls les messages d’erreur restent potentiellement visibles. Il est donc parfaitement possible d’exécuter ce module de manière totalement silencieuse (hors erreurs, bien entendu)


5.1. Module d’administration

Il s’agit du même module du panneau de configuration évoqué ci-dessus, visible et donc accessible uniquement si l’utilisateur a les droits d’administrateur. Ce module présente entre autre un onglet de gestion des mises à jour


6. Module d’administration dans le panneau de configuration

Il s’agit du module que l’administrateur du TS peut utiliser pour configurer les différents utilisateurs du TS.


Ce module peut éventuellement aussi être utilisé dans un réseau local, pour autant que son utilisateur ait les droits d’administrateur sur le poste local : bien entendu, ces paramètres n’affecteront que le ou les utilisateurs sur le même poste.


Ce module n’accessible donc que si l’utilisateur courant a les droits d’administrateur, et peut donc écrire en particulier dans la configuration de l’application. Un utilisateur standard, donc sans droits d’administrateur, pourra même ne pas voir ce module suivant les paramètres.