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:38] 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 78: Ligne 109:
 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 ===== ===== Architecture technique des postes clients =====
  
 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) : 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) :
   * le **client lourd**, exécutable Delphi installé (ou exécuté directement) sur le poste, qui offre l'ensemble des fonctionnalités (fichier et comptabilité) ;   * 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 **version full-web**, accessible depuis un simple navigateur, qui permet de consulter et modifier le fichier, sans accès à la comptabilité ni aux états.+  * 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).
  
 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. 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.
Ligne 106: Ligne 137:
  
 ==== Compatibilité et prérequis ==== ==== 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.
  
-**Systèmes d'exploitation** — le client lourd est développé et testé sur Windows 10 et Windows 11 (hors éditions "S", qui interdisent l'installation de logiciels tiers). La compatibilité avec Windows 8/8.1 n'est plus testée depuis la V8 mais reste visée dans la mesure du possible. Mac et Linux ne sont pas supportés nativement : leur usage n'est possible que via un émulateur (CrossOver, Parallels pour Mac ; Wine, PlayOnLinux pour Linux), non testé officiellement par nos équipes. La version full-web reste l'alternative recommandée sur ces systèmes, puisqu'elle ne dépend que d'un navigateur standard. 
  
-**Réseau** — un débit minimum de 2 Mbit/s et une latence inférieure à 40 ms sont requis pour un fonctionnement correct. Le port **8086** doit être ouvert ; les ports 8080 et 9000 peuvent être nécessaires en complément selon la configuration réseau du poste. 
- 
-**Machine** — processeur x86/amd64, moins de 200 Mo d'espace disque requis, résolution minimale 1280×1024, mémoire 4 Go minimum (8 Go recommandés sous Windows 10 et supérieur). 
- 
-**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. 
- 
-On trouvera la spécification technique complète des postes sur lesquels LoGeAs peut fonctionner à la page [[version:web:technique:machine|Sur quel ordinateur peut-on utiliser LoGeAs ?]]. 
 ===== Architecture de supervision ===== ===== 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. +Il existe actuellement deux niveaux de supervision : 
-Commençons tout d’abord par rappeler ce qu’est un incident dans un contexte ITIL. +  * **Une supervision "humaine" des serveurs (notammentbon démarrage le matin) et des sauvegardes** 
-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. +  * Une supervision externe de nos machines au niveaux proxmox (sans accès au contenu) par la société [[https://www.altsysnet.com/|altsysnet]]
- +
-Le lien entre la supervision et la gestion des incidents s’appuie particulièrement sur deux points +
-  * La génération automatique d’incident pour les alertes critiques fonctionnelles remontées par l’outil de supervision+
-  * La liaison directe avec la base de connaissance de la gestion des incidents.  +
-Ainsila 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 Serviceou SLA pour reprendre un terme ITIL (Service Level Agreement). +
- +
-Le choix de l’entreprise s’est finalement porté sur Zabbix. +
-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.+
 ===== 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.