meta données pour cette page
  •  

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
certif:dat [2026/08/01 16:28] – [Architecture technique des postes clients] nicolascertif:dat [2026/08/11 14:34] (Version actuelle) – [Gestion des sources, des versions et dépôt] nicolas
Ligne 19: Ligne 19:
  
 Ce document s'adresse aux auditeurs en charge de la certification ainsi qu'aux équipes techniques internes chargées de la maintenance et de l'évolution de la solution. Il est mis à jour à chaque évolution significative de l'architecture technique. Ce document s'adresse aux auditeurs en charge de la certification ainsi qu'aux équipes techniques internes chargées de la maintenance et de l'évolution de la solution. Il est mis à jour à chaque évolution significative de l'architecture technique.
 +
 +===== Outils et méthodologie de développement =====
 +==== Langages et frameworks ====
 +  * **Serveurs principaux** (app.logeas.fr : bases-ws, monespace) : Delphi 12, avec l'ORM **mORMot 1**.
 +  * **Serveurs secondaires** (app.logeas.ovh : nono, etc.) : Lazarus (Free Pascal), avec l'ORM **mORMot 2**.
 +  * **Client lourd** : Delphi 12, s'appuyant notamment sur les bibliothèques **FastReport** (génération des états) et **DevExpress** (composants d'interface).
 +  * **Base de données** : SQLite, une base distincte par client afin de limiter les risques et les volumes traités ; chiffrement AES via la bibliothèque **SynCrypto** (Synopse) depuis la version 9.5.1.
 +  * **Interface légère (full-web)** : développée en **Angular** (v21), avec les bibliothèques de composants **DevExtreme** et **Syncfusion** (tableaux de données, graphiques, cartes). La génération des états s'appuie sur **Stimulsoft Reports** (équivalent full-web du FastReport utilisé côté client lourd). Les exports de documents (Excel, PDF, CSV) reposent sur ExcelJS, jsPDF/pdfmake et PapaParse. Le projet consomme également des bibliothèques internes partagées (**ngx-interface-ui**, **ngx-logeascom-ui**, **ngx-logeasweb-ui**), issues d'un monorepo de composants communs ("logeas-lib"). Les tests sont réalisés avec **Jest** (tests unitaires) et **Playwright** (tests d'intégration).
 +
 +==== Méthodologie de conception ====
 +Historiquement, LoGeAs a été développé depuis 1999 selon un modèle en spirale (cf. ci-dessus). En pratique aujourd'hui, le développement s'organise en **mini-projets sur GitLab**, suivant un fonctionnement proche du **Kanban**, bien que celui-ci reste largement "théorique" : les mini-projets sont fréquemment interrompus par la prise en charge d'urgences (corrections, support), ce qui rompt la continuité du flux Kanban classique.
 +==== Suivi des anomalies et des évolutions ====
 +Le suivi des tickets s'appuie sur **deux outils internes distincts**, plutôt qu'un outil de gestion de projet plus lourd comme l'était précédemment projecQtOr :
 +  * un outil côté **client** (remontée des demandes et anomalies) ;
 +  * un outil côté **développement** (suivi technique, priorisation, correctifs).
 +Ce choix d'outillage léger s'explique directement par la taille de l'équipe de développement, très réduite (environ **1,5 ETP**). Un outil de gestion de projet centralisé et formalisé, dimensionné pour des équipes plus importantes, représenterait une charge de suivi disproportionnée par rapport à la capacité réelle de traitement. La séparation en deux outils permet au contraire de garder côté client une interface simple de remontée des besoins, sans étape de qualification technique préalable, et côté développement un backlog directement actionnable, sans couche de gestion de projet intermédiaire.
 +
 +Cette contrainte de taille explique également pourquoi le fonctionnement Kanban reste "théorique" : avec une capacité de développement aussi limitée, la moindre urgence client (anomalie bloquante, incident) mobilise mécaniquement la totalité de la capacité disponible et interrompt le mini-projet en cours, faute de marge permettant d'absorber l'urgence sans arbitrage. Il ne s'agit donc pas d'un défaut d'application de la méthode, mais d'une conséquence structurelle du dimensionnement de l'équipe.
 +
 +**Cartographie fonctionnelle** ([[https://logeas-web.fr/carto]]) : référentiel central des composants logiciels, des tests, et de leurs liens avec les fonctionnalités et les marques de certification (NF203/NF552).
 +
 +==== Gestion des sources, des versions et dépôt ====
 +
 +Le code source est hébergé sur **GitLab**, qui a totalement remplacé l'ancien dépôt SVN. Les développeurs interagissent avec le dépôt via le client graphique **SourceTree**.
 +
 +La stratégie de branches suit un modèle **une branche par version** : chaque nouvelle version du logiciel est développée sur une branche dédiée. Lors de la mise en ligne (déploiement en production) d'une version, le numéro de version est incrémenté, formalisant le passage à la version suivante. Tous les clients sont maintenus sur la dernière version **Release** ; des écarts mineurs de **Build** peuvent exister suite à des correctifs ciblés.
 +
 +L'usage de Git constitue également la méthode retenue pour répondre à l'exigence de preuve d'authenticité du logiciel audité (art. 4.3.6 "Dépôt des sources et preuve d'authenticité du logiciel audité") : à défaut de dépôt des sources auprès d'un tiers, chaque commit est identifié par une empreinte cryptographique (hash SHA) calculée sur l'ensemble du contenu et de l'historique, figeant de façon incontestable l'état exact des sources à un instant donné. Lors d'un audit, l'empreinte du commit correspondant à la branche de la version auditée peut être communiquée à l'organisme certificateur pour vérification de l'authenticité et de l'intégrité du code.
 +
 +**Pour en savoir plus : [[certif:questionnaire:procedure:develop:gestionversion]]**
 +
  
 ===== Architecture globale de l'infrastructure ===== ===== Architecture globale de l'infrastructure =====
Ligne 73: Ligne 104:
  
 {{ :certif:serveurs_web_iis.svg }} {{ :certif:serveurs_web_iis.svg }}
 +NB : SVG stocké sur le wiki, éditable par exemple avec Inkscape.\\ 
 +\\ 
 +{{ :certif:cheminement_message_logeas_technique.svg |}}
 NB : SVG stocké sur le wiki, éditable par exemple avec Inkscape. NB : SVG stocké sur le wiki, éditable par exemple avec Inkscape.
 +
  
 ===== Architecture technique des postes clients ===== ===== Architecture technique des postes clients =====
-LoGeAs est proposé actuellement en deux versions : 
-==== Le client installé (du lourd) ==== 
-Il s'agit d'un simple exécutable **__compilé uniquement pour windows__**, il n' 
-Pour répondre au mieux aux contraintes des installations sur les postes professionnels et sur les systèmes non gérés par LoGeAs (comme Linux ou Mac), nous avons choisi de livrer la nouvelle version sous la forme d’un simple fichier (compressé ou non). Les fichiers secondaires utilisés pour le paramétrage sont maintenant stockés en base de données et téléchargés à la demande. Ceci permettra aussi de les faire évoluer sans avoir besoin de faire une nouvelle version. C’est en particulier le cas des états.  
-Il est donc possible de mettre l’exécutable de LoGeAs sur une clef USB 3 et de le transporter d’ordinateur en ordinateur. 
-==== Utilisateur avancé ==== 
-Lors du lancement, à côté de l’exécutable LoGeAs, est créé un dossier « LoGeAsUserData » dans lequel sont stockés : 
-  * les informations de connexion (qui peuvent être régénérées facilement si besoin) 
-  * des dossiers temporaires à LoGeAs, vidés régulièrement automatiquement 
-  * les états « personnalisés » que vous ne partagez pas avec vos collègues. Il est alors de votre responsabilité d’en faire des sauvegardes. 
-  * des sauvegardes des états modifiés 
-=== Sur quels postes utiliser LoGeAs ? === 
-On trouvera la spécification technique des postes sur lesquels LoGeAs peut fonctionner à la page **"[[version:web:technique:machine]]"** 
-===== Architecture de supervision ===== 
-Nous aborderons ici le thème de la supervision et son intégration dans le processus de gestion des incidents au sens ITIL du terme. 
-Commençons tout d’abord par rappeler ce qu’est un incident dans un contexte ITIL. 
-Un incident est une interruption inattendue d'un service. Il perturbe les opérations normales et affecte donc la productivité de l'utilisateur final. Un incident peut être provoqué par le mauvais fonctionnement d’un actif ou par une panne de réseau, en exemple :  l’indisponibilité d’une imprimante. 
  
-Le lien entre la supervision et la gestion des incidents s’appuie particulièrement sur deux points : +L'accès à LoGeAs depuis un poste client se fait selon deux modes complémentaires, décrits dans le Dossier de Conception Générale (DCG) : 
-  * La génération automatique d’incident pour les alertes critiques fonctionnelles remontées par l’outil de supervision. +  * le **client lourd**, exécutable Delphi installé (ou exécuté directement) sur le poste, qui offre l'ensemble des fonctionnalités (fichier et comptabilité) ; 
-  * La liaison directe avec la base de connaissance de la gestion des incidents.  +  * la **version full-web**, accessible depuis un simple navigateur, qui permet de consulter et modifier le fichier, sans accès à la comptabilité ni aux états à ce jour (en constante évolution).
-Ainsi, la supervision permet de : +
-  * Prévenir certains incidents par des systèmes de suivi d’indicateurs clefs et des alertes préventives adaptées. +
-  * Ordonnancer les incidents selon une classification adaptée aux services ou aux besoins de l’entreprise. +
-  * Optimiser la détection des incidents par un système d’alertes optimisées. +
-  * Optimiser la résolution des incidents par la mise en place de procédure optimisées et en amélioration continue (mise à jour régulière de la base de connaissance afin de la faire correspondre aux nouvelles problématiques rencontrées).+
  
-Les bilans fournis par un outil de supervision sur l’état et la disponibilité des services permettent également de valider ou d’invalider une CNS (Contrats de Niveau de Service) ou SLA pour reprendre un terme ITIL (Service Level Agreement).+Cette distinction a une incidence directe sur l'architecture technique : le client lourd communique avec les serveurs applicatifs (app.logeas.fr / app.logeas.ovh) via l'ORM **mORMot**, en REST/JSON au travers d'une connexion HTTPS ; la version full-web utilise une connexion HTTP classique de navigateur à serveur.
  
-Le choix de l’entreprise s’est finalement porté sur Zabbix. +==== Déploiement, portabilité et mise à jour ==== 
-En effet, outre la possibilité d’intégrer Zabbix à notre logiciel de support de façon simple, il s’avère que Zabbix dispose d’un template permettant de superviser les sauvegardes gérées par le logiciel Ipérius Backup, nous offrant ainsi la possibilité de nous alerter par sms, et de créer un ticket de support sur OTRS lorsqu’une sauvegarde est en statut d’échec ou terminée avec des erreurs, en sus des courriels. + 
-De plus, la possibilité de créer et de customiser simplement les déclencheurs et donc d’affiner la supervision des services déterminés comme étant critique est un réel avantage.+Pour répondre au mieux aux contraintes des installations sur les postes professionnels et sur les systèmes non gérés par LoGeAs, la version installée est livrée sous la forme d'un simple fichier exécutable (compressé ou non). Les fichiers secondaires utilisés pour le paramétrage (notamment les états) sont stockés en base de données et téléchargés à la demande, ce qui permet de les faire évoluer sans nécessiter de nouvelle version. 
 + 
 +Il est ainsi possible de mettre l'exécutable de LoGeAs sur une clef USB 3 et de le transporter d'un ordinateur à l'autre : aucune donnée comptable n'est stockée localement, l'ensemble résidant sur les serveurs applicatifs. 
 + 
 +La détection et la distribution des mises à jour du logiciel sont assurées par le portail dédié **maj.logeas.fr** (cf. section "Architecture technique des serveurs applicatifs"). 
 + 
 +==== Utilisateur avancé ==== 
 + 
 +Lors du lancement, à côté de l'exécutable LoGeAs, est créé un dossier « LoGeAsUserData » dans lequel sont stockés : 
 +  * les informations de connexion (qui peuvent être régénérées facilement si besoin) ; 
 +  * des dossiers temporaires à LoGeAs, vidés régulièrement automatiquement ; 
 +  * les états « personnalisés » que vous ne partagez pas avec vos collègues (il est alors de votre responsabilité d'en faire des sauvegardes) ; 
 +  * des sauvegardes des états modifiés. 
 + 
 +Ce dossier ne contient aucune donnée comptable ou métier : en cas de perte ou de vol du poste (ou de la clef USB), seuls les identifiants de connexion et les états personnalisés sont exposés — les premiers étant régénérables, les seconds relevant de la responsabilité de l'utilisateur. 
 + 
 +==== Compatibilité et prérequis ==== 
 +^Client^se reportez à la page^ 
 +|LoGeAs Installation Windows|[[https://wiki-logeas.fr/logeas/doku.php?id=version:web:technique:machine]]|  
 +|Logeas-web.fr|[[https://wiki-logeas.fr/logeas-web/doku.php?id=general]]| 
 +**Sauvegarde** — bien qu'aucune donnée métier ne soit stockée localement, une sauvegarde du poste reste recommandée, de préférence externe au PC et aux locaux. 
 + 
 + 
 +===== Architecture de supervision ===== 
 +Il existe actuellement deux niveaux de supervision : 
 +  * **Une supervision "humaine" des serveurs (notamment, bon démarrage le matin) et des sauvegardes** 
 +  * Une supervision externe de nos machines au niveaux proxmox (sans accès au contenu) par la société [[https://www.altsysnet.com/|altsysnet]]
 ===== Robustesse ===== ===== Robustesse =====
 Dans le cadre de la certification NF552 un audit de robustesse à été réalisé sur le progiciel en octobre 2021. Dans le cadre de la certification NF552 un audit de robustesse à été réalisé sur le progiciel en octobre 2021.