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 17:30] – [Langages et frameworks] nicolascertif:dat [2026/08/11 14:34] (Version actuelle) – [Gestion des sources, des versions et dépôt] nicolas
Ligne 29: Ligne 29:
  
 ==== Méthodologie de conception ==== ==== 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.
  
-LoGeAs est développé depuis 1999 selon un modèle **en spirale** : le processus est représenté par une spirale plutôt qu'une séquence linéaire, chaque boucle correspondant à une étape (définition des objectifs, estimation et réduction des risques, développement et validation, planification).+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.
  
-==== Gestion des sources et des versions ====+**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).
  
-  * Versionning des codes sources : **SVN** (cf. [[certif:procedure:develop:gestionsvn|procédure #30]]). +==== Gestion des sources, des versions et dépôt ==== 
-  * Dépôt des codes sources : cf. [[certif:procedure:develop:proceduremiseaucoffredescodes|procédure #09]]. + 
-  * Diffusion des versions : tous les clients sont maintenus sur la dernière version **Release** ; des écarts mineurs de **Build** peuvent exister suite à des correctifs ciblés (cf. [[certif:procedure:develop:gestionversion|procédure #06]]).+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]]**
  
-==== Suivi des anomalies et des évolutions ==== 
  
-  * **projecQtOr** ([[https://projet.logeas.fr/]]) : suivi des tickets et anomalies remontées, méthodologie décrite en [[certif:procedure:develop:gestionprojeqtor|procédure dédiée]]. 
-  * **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). 
 ===== Architecture globale de l'infrastructure ===== ===== Architecture globale de l'infrastructure =====
 ==== Vue d'ensemble des composants — serveur applicatif, postes clients, outils de supervision, prestataires (Prosoluce) ==== ==== Vue d'ensemble des composants — serveur applicatif, postes clients, outils de supervision, prestataires (Prosoluce) ====