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:47] – [Architecture de supervision] 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 =====