Dossier d’Architecture Technique

Ce document constitue le Dossier d'Architecture Technique (DAT) du progiciel LoGeAs. Il a pour objet de décrire en profondeur l'implémentation technique de la solution, dans le cadre de la démarche de certification NF203/NF552, en complément du Dossier de Conception Générale (DCG) et du Dossier de Spécifications Fonctionnelles (DSF).

Il couvre notamment :

• les technologies, langages et frameworks utilisés pour le développement et l'exécution de la solution ;
• l'architecture détaillée du système, incluant la nature et le sens des flux entre les différents composants (serveurs applicatifs, postes clients, outils de supervision) ;
• les protocoles de communication utilisés entre ces composants ;
• les algorithmes de signature et de hachage employés pour garantir l'intégrité, l'inaltérabilité et la traçabilité des données (enregistrements en base, fichiers, piste d'audit) ;
• l'architecture de supervision et son articulation avec la gestion des incidents (approche ITIL) ;
• l'historique versionné de ces éléments techniques, afin de tracer la conformité du logiciel aux marques NF successives (NF203, NF552) et au référentiel FIDELE (R19).

Les sujets relatifs à la sauvegarde des données, aux archives fiscales, au FEC et à la RGPD sont traités dans le DSF et ne sont pas repris ici.

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.

• 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).

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.

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).

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 : gestionversion

L'infrastructure physique de LoGeAs Informatique s'articule autour de trois sites. Le site principal est hébergé à Saint Gaudens, dans le datacenter de Prosoluce, au sein d'une demi baie dédié à notre activités. Il héberge les deux nœuds de virtualisation Proxmox — LOGEAS1 et LOGEAS2, serveurs SuperMicro — qui portent l'ensemble des machines virtuelles applicatives. Ces deux serveurs sont reliés au routeur RB3011 (Mikrotik), point de sortie réseau du site.

Le site de Labarthe Inard héberge deux zones distinctes : la baie Logeas informatique et la salle privée. La baie Logeas informatique reçoit la connectivité du site de Saint Gaudens par deux voies complémentaires : une liaison Internet classique, via une fibre privée relie directement le site à notre baie dans le data-ceenter, et une liaison LTE de secours (Prosoluce/Orange), aboutissant au boîtier Résiliencia. Cette redondance des accès WAN vise à garantir la continuité de service en cas de défaillance de l'un des deux liens.

Enfin, la salle privée de Labarthe Inard, alimentée depuis la baie Logeas informatique via Résiliencia, héberge trois serveurs de stockage supplémentaires (SOCIUS NAS2, SOCIUS NAS3, NICOLAS NAS) raccordés à un commutateur dédié.

NB : SVG stocké sur le wiki éditable par exemple avec Inkscape

Les serveurs web applicatifs sont hébergés sous forme de machines virtuelles sur les nœuds de virtualisation Proxmox du site de Saint-Gaudens (LOGEAS1 et LOGEAS2). Le serveur web utilisé est Microsoft IIS, qui a remplacé nginx sur ces environnements.

Ce serveur héberge deux sites, chacun exposé sur une adresse IP publique dédiée. Les deux sites sont exposés exclusivement en HTTPS. Le module Application Request Routing (ARR) et le proxy IIS sont installés sur ce serveur.

NB : le site bases.logeas.fr, présent dans la configuration technique, est hors service et n'est pas documenté ici.

Ce serveur héberge l'ensemble des sites secondaires de l'écosystème LoGeAs. Il intègre en complément un moteur PHP (FastCGI), notamment utilisé par le wiki intranet, ainsi que le module ARR/proxy.

NB : SVG stocké sur le wiki, éditable par exemple avec Inkscape.

NB : SVG stocké sur le wiki, éditable par exemple avec Inkscape.

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é) ;
• 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.

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”).

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.

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.

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é altsysnet

Dans le cadre de la certification NF552 un audit de robustesse à été réalisé sur le progiciel en octobre 2021. On trouvera les grandes lignes et les points d'évolution ainsi que les actions mené à la page Constat de l'audit de robustesse 2021

On trouvera sur le page Partie cryptologie de LoGeAs (chaine aléatoire, cryptage, signature...) l'ensemble des informations liées à la signature des fichiers dans LoGeAs (FEC, Sauvegarde, Archive fiscale)

On pourra ce reporter à la page Partie cryptologie de LoGeAs (chaine aléatoire, cryptage, signature...) pour avoir des informations sur la technique utilisée par LoGeAs pour signer les fichiers et les enregistrements

A partir de la version 9.5, la structure de la piste d'audit évolue pour se mettre en conformité avec la nouvelle version 4.0 du du R19.

N°	Version initiale du logiciel	Schéma explicatif	Commentaires
01	Non référencé (buggée)
02	A partir de la version 9.5		la structure de la piste d'audit évolue pour se mettre en conformité avec la nouvelle version 4.0 du du R19 La signature de chaque enregistrement est constituée avec la suite des champs : * “ID” : Identifiant de l'événement * “Code” : Code de l'événement * “Intitule” : Intitulé du code / Description de l'événement * “GDHDate” : Horodatage GDH (sous la forme AAAAMMJJHHMMSS) * “CreatedUserSUID” : Code opérateur * “Champ vide” correspondant au code de caisse (non utilisé dans LoGeAs) * “N” s'il existe une signature sur l'enregistrement précédent “O” sinon * “Signature de l'enregistrement précédent”
03	A partir de la version 10.0

Bien que complétée par un texte en clair, chaque ligne d'entrée dans ce journal (JET) est taguée, conformément à la NF203, par un code dont vous trouverez la signification ci-dessus.