Contexte
Le laboratoire Galaxy Swiss Bourdin (GSB) est un groupe pharmaceutique dont les visiteurs médicaux génèrent des frais professionnels nécessitant un suivi par le service comptabilité.
Pour répondre à ce besoin, une application web de gestion des frais, basée sur une architecture MVC, est en cours de développement.
Notre mission consiste à poursuivre ce développement et à mettre en place une solution d’hébergement sécurisée afin de garantir la disponibilité et la confidentialité des données.
Pour répondre à ce besoin, une application web de gestion des frais, basée sur une architecture MVC, est en cours de développement.
Notre mission consiste à poursuivre ce développement et à mettre en place une solution d’hébergement sécurisée afin de garantir la disponibilité et la confidentialité des données.
Partie Réseau
Le serveur web a été migré vers un environnement virtualisé sous Debian 12 avec une IP fixe, afin d’héberger les sites du domaine swiss-galaxyb.
Plusieurs services ont été configurés : Apache2, PHP, Bind9 pour le DNS, ainsi qu’un serveur FTPS sécurisé pour le transfert de fichiers. La liaison avec une base de données distante a également été mise en place.
Les trois sites sont accessibles via leurs noms de domaine grâce à la configuration DNS et des VirtualHosts, validés avec dig et nslookup.
La sécurité a été renforcée par HTTPS (SSL/TLS), FTPS chiffré et l’isolation des comptes utilisateurs sans accès SSH.
Un système de sauvegarde automatisé (local + cloud via rclone) a été mis en place avec des tâches cron.
Enfin, la sécurisation des échanges avec la base de données distante est en cours (tunnel SSH ou TLS).
Plusieurs services ont été configurés : Apache2, PHP, Bind9 pour le DNS, ainsi qu’un serveur FTPS sécurisé pour le transfert de fichiers. La liaison avec une base de données distante a également été mise en place.
Les trois sites sont accessibles via leurs noms de domaine grâce à la configuration DNS et des VirtualHosts, validés avec dig et nslookup.
La sécurité a été renforcée par HTTPS (SSL/TLS), FTPS chiffré et l’isolation des comptes utilisateurs sans accès SSH.
Un système de sauvegarde automatisé (local + cloud via rclone) a été mis en place avec des tâches cron.
Enfin, la sécurisation des échanges avec la base de données distante est en cours (tunnel SSH ou TLS).
Partie Développement
Le pôle SLAM a poursuivi le développement de l’application de gestion des frais en vérifiant les fonctionnalités existantes et en développant la partie comptable.
La gestion des rôles utilisateurs a été ajoutée, avec adaptation de la base de données et du système d’authentification.
L’application, développée en MVC, a été testée puis déployée sur le serveur Debian mis en place par le pôle SISR.
La gestion des rôles utilisateurs a été ajoutée, avec adaptation de la base de données et du système d’authentification.
L’application, développée en MVC, a été testée puis déployée sur le serveur Debian mis en place par le pôle SISR.
Situation d’avancement du projet
Dans le cadre du projet AP6, j’ai occupé le rôle de chef de projet, en assurant la planification, le suivi des tâches et la coordination entre les pôles SISR et SLAM.
En parallèle, j’ai pris en charge la partie SISR : mise en place du serveur Debian, configuration DNS (Bind9), FTPS, HTTPS et déploiement des sauvegardes automatisées (local et cloud).
Le projet s’est déroulé sur plusieurs semaines avec un suivi régulier et une collaboration étroite entre les équipes.
Cette expérience m’a permis de renforcer mes compétences techniques et ma gestion de projet, malgré un POC de sécurisation non finalisé.
En parallèle, j’ai pris en charge la partie SISR : mise en place du serveur Debian, configuration DNS (Bind9), FTPS, HTTPS et déploiement des sauvegardes automatisées (local et cloud).
Le projet s’est déroulé sur plusieurs semaines avec un suivi régulier et une collaboration étroite entre les équipes.
Cette expérience m’a permis de renforcer mes compétences techniques et ma gestion de projet, malgré un POC de sécurisation non finalisé.
Partie Réseau
Reconstitution du serveur web GSB
Le serveur web a été reconstitué sous Debian 12 dans un environnement virtualisé, avec une configuration réseau en IP fixe.
Les services essentiels ont été déployés : Apache2, PHP, Bind9 et un serveur FTPS sécurisé (ProFTPD avec TLS).
L’objectif était de fournir un environnement stable et sécurisé permettant le déploiement de l’application par le pôle SLAM.
Les services essentiels ont été déployés : Apache2, PHP, Bind9 et un serveur FTPS sécurisé (ProFTPD avec TLS).
L’objectif était de fournir un environnement stable et sécurisé permettant le déploiement de l’application par le pôle SLAM.
Mise en place de la liaison avec le serveur de base de données
La base de données est hébergée sur un serveur distant afin d’assurer une meilleure sécurité et une isolation des données.
La liaison avec l’application web a été configurée pour permettre son bon fonctionnement.
La sécurisation des échanges est en cours, avec l’étude de solutions telles que le tunnel SSH ou le chiffrement TLS (POC en cours).
La liaison avec l’application web a été configurée pour permettre son bon fonctionnement.
La sécurisation des échanges est en cours, avec l’étude de solutions telles que le tunnel SSH ou le chiffrement TLS (POC en cours).
Gestion des domaines
Le service DNS Bind9 a été configuré afin de rendre les sites accessibles via leurs noms de domaine.
Les zones DNS ont été mises en place (SOA, A, CNAME, NS) et validées avec les outils dig et nslookup.
Les domaines pointent vers le serveur et sont gérés via des VirtualHosts Apache avec des répertoires et logs dédiés.
Les zones DNS ont été mises en place (SOA, A, CNAME, NS) et validées avec les outils dig et nslookup.
Les domaines pointent vers le serveur et sont gérés via des VirtualHosts Apache avec des répertoires et logs dédiés.
Mise à jour des sites
Des comptes FTP dédiés ont été créés pour chaque site, avec isolation des utilisateurs (chroot) et sans accès SSH.
Les transferts sont sécurisés en FTPS (TLS) et ont été validés via FileZilla.
Les transferts sont sécurisés en FTPS (TLS) et ont été validés via FileZilla.
Sécurisation du serveur web
Le protocole HTTPS a été activé sur les trois domaines via Apache2, avec génération d’un certificat SSL/TLS auto-signé.
Des VirtualHosts sécurisés (port 443) ont été configurés pour chaque site afin de chiffrer les échanges.
Le certificat étant auto-signé, un avertissement navigateur est présent.
Des VirtualHosts sécurisés (port 443) ont été configurés pour chaque site afin de chiffrer les échanges.
Le certificat étant auto-signé, un avertissement navigateur est présent.
Répartition de charges
La mise en place d’une solution de répartition de charge n’a pas pu être réalisée faute de temps.
Cette amélioration aurait impliqué l’ajout d’un second serveur et l’utilisation d’outils comme HAProxy pour assurer la haute disponibilité.
Cela constitue un axe d’amélioration pour de futurs projets.
Cette amélioration aurait impliqué l’ajout d’un second serveur et l’utilisation d’outils comme HAProxy pour assurer la haute disponibilité.
Cela constitue un axe d’amélioration pour de futurs projets.
Sécurisation des échanges
La sécurisation des échanges entre le serveur web et la base de données distante est un enjeu majeur pour garantir la confidentialité des données.
Un POC est en cours afin d’évaluer des solutions comme le tunnel SSH, le VPN ou le chiffrement TLS.
Ces travaux visent à renforcer la sécurité globale de l’infrastructure.
Un POC est en cours afin d’évaluer des solutions comme le tunnel SSH, le VPN ou le chiffrement TLS.
Ces travaux visent à renforcer la sécurité globale de l’infrastructure.
Partie Développement
Vérification des fonctionnalités existantes
Le pôle SLAM a vérifié le bon fonctionnement de l’application (saisie, affichage et enregistrement des données).
Des tests ont été réalisés afin de garantir sa stabilité avant les évolutions.
Des tests ont été réalisés afin de garantir sa stabilité avant les évolutions.
Développement de la partie “Service comptable”
Le pôle SLAM a développé la partie comptable de l’application pour la validation des fiches de frais.
La gestion des états et du suivi des demandes a été mise en place.
La gestion des états et du suivi des demandes a été mise en place.
Mise en ligne de l’application
L’application a été déployée sur le serveur de production après validation en local.
Elle repose sur une architecture MVC garantissant sa stabilité et son évolutivité.
Elle repose sur une architecture MVC garantissant sa stabilité et son évolutivité.
Partie Juridique
Qualification juridique des informations contenues dans la base de données
Les données de l’application (identité, frais, justificatifs) sont des données personnelles au sens du RGPD.
Elles doivent être protégées et traitées selon les règles de sécurité, de confidentialité et de minimisation.
Elles doivent être protégées et traitées selon les règles de sécurité, de confidentialité et de minimisation.
Base juridique du recueil des informations et nécessité du consentement
Les données sont collectées dans un cadre professionnel pour la gestion des frais.
Le traitement repose sur l’exécution du contrat (RGPD), sans nécessité de consentement, mais avec obligation d’information des utilisateurs.
Le traitement repose sur l’exécution du contrat (RGPD), sans nécessité de consentement, mais avec obligation d’information des utilisateurs.
Principales règles applicables au traitement des informations
Le traitement des données doit respecter les principes du RGPD : finalité, minimisation, exactitude et durée de conservation.
Des mesures de sécurité (chiffrement, mots de passe, sauvegardes) doivent être mises en place, tout en garantissant les droits des utilisateurs.
Des mesures de sécurité (chiffrement, mots de passe, sauvegardes) doivent être mises en place, tout en garantissant les droits des utilisateurs.
Protection de la base de données par le droit d’auteur
La base de données n’est pas protégée par le droit d’auteur, car sa structure repose sur des critères techniques et non sur une création originale.
Autre régime de protection applicable : le droit sui generis des bases de données
La base de données est protégée par le droit sui generis, qui empêche l’extraction ou la réutilisation non autorisée de son contenu.
Compétences mobilisées – Bloc 1
- B1.1 – Gérer le patrimoine informatique : mise en place d’un serveur Debian sécurisé avec sauvegardes automatisées.
- B1.2 – Répondre aux incidents et aux demandes : diagnostic et correction des services (Apache, DNS, FTPS).
- B1.3 – Développer la présence en ligne : configuration DNS et mise en ligne des sites via VirtualHosts.
- B1.4 – Travailler en mode projet : planification, suivi et coordination entre SISR et SLAM.
- B1.5 – Mettre à disposition un service : mise en production d’un environnement web sécurisé et fonctionnel.
- B1.6 – Organiser son développement professionnel : montée en compétences en administration systèmes et réseaux.