Contexte
Le laboratoire Galaxy Swiss Bourdin (GSB) est un laboratoire pharmaceutique issu de la fusion entre le géant américain Galaxy et le conglomérat européen Swiss Bourdin. Il exerce une activité de conseil et d’information médicale auprès des prescripteurs tels que les médecins et pharmaciens. Ce rôle est assuré par ses 480 visiteurs médicaux en France métropolitaine, chargés de se déplacer pour présenter les nouveaux produits pharmaceutiques du laboratoire.
Ces déplacements et les différentes actions menées sur le terrain engendrent des frais professionnels devant être gérés et pris en charge par le service comptabilité. Dans ce cadre, une application web de gestion des frais, conçue selon une architecture MVC, est en cours de développement.
La conception de cette application a été confiée à une société de services informatiques au sein de laquelle notre équipe intervient. Notre mission consiste à poursuivre le développement de l’application et à proposer une solution d’hébergement sécurisée, garantissant la fiabilité et la confidentialité des données.
Ces déplacements et les différentes actions menées sur le terrain engendrent des frais professionnels devant être gérés et pris en charge par le service comptabilité. Dans ce cadre, une application web de gestion des frais, conçue selon une architecture MVC, est en cours de développement.
La conception de cette application a été confiée à une société de services informatiques au sein de laquelle notre équipe intervient. Notre mission consiste à poursuivre le développement de l’application et à proposer une solution d’hébergement sécurisée, garantissant la fiabilité et la confidentialité des données.
Partie Réseau
Dans le cadre du projet GSB, le serveur web a été migré vers un environnement virtualisé INTRALAB B (groupe 2). L’objectif était de reconstituer un serveur web sous Debian 12 destiné à héberger les sites du domaine swiss-galaxyb, avec une adresse IP fixe 172.18.158.150 et le hostname InterlabB.
Ce déploiement a nécessité l’installation et la configuration de plusieurs services essentiels : Apache2 pour l’hébergement web, PHP pour le traitement dynamique des pages, FTPS (ProFTPD avec TLS) pour les transferts de fichiers sécurisés, Bind9 pour la gestion des noms de domaine, ainsi que la liaison avec la base de données ap5_BDMEDOCLABn hébergée sur un serveur distant dédié.
Les trois sites du laboratoire sont accessibles via leurs noms de domaine — www.swiss-galaxyb.com, www.swiss-galaxyb-france.fr et www.swiss-galaxyb-europe.eu — grâce à la configuration de zones DNS et de VirtualHosts Apache dédiés, validée à l’aide des outils de diagnostic réseau dig et nslookup.
Les développeurs peuvent mettre à jour chaque site à tout moment via un client FTP sécurisé grâce à des comptes dédiés (websgncom, websgnfr, websgneu). Chaque compte est isolé dans son propre répertoire et ne dispose pas d’accès SSH afin de limiter les risques de sécurité.
Plusieurs mécanismes de sécurité ont également été mis en place : activation du protocole HTTPS avec des certificats SSL/TLS auto-signés pour les trois domaines, ainsi que l’utilisation de connexions FTPS chiffrées en TLS 1.2 et TLS 1.3 pour les transferts de fichiers.
Un système complet de sauvegarde et de restauration automatisé a été déployé. Des sauvegardes locales quotidiennes sont réalisées sur le serveur, tandis qu’une copie externalisée est envoyée vers Google Drive via l’outil rclone. Ces opérations sont planifiées automatiquement grâce à des tâches cron.
La dernière étape du projet consiste à sécuriser les échanges entre le serveur web et le serveur de base de données distant, notamment par la mise en place d’un tunnel SSH ou d’un chiffrement TLS pour les connexions MySQL.
Ce déploiement a nécessité l’installation et la configuration de plusieurs services essentiels : Apache2 pour l’hébergement web, PHP pour le traitement dynamique des pages, FTPS (ProFTPD avec TLS) pour les transferts de fichiers sécurisés, Bind9 pour la gestion des noms de domaine, ainsi que la liaison avec la base de données ap5_BDMEDOCLABn hébergée sur un serveur distant dédié.
Les trois sites du laboratoire sont accessibles via leurs noms de domaine — www.swiss-galaxyb.com, www.swiss-galaxyb-france.fr et www.swiss-galaxyb-europe.eu — grâce à la configuration de zones DNS et de VirtualHosts Apache dédiés, validée à l’aide des outils de diagnostic réseau dig et nslookup.
Les développeurs peuvent mettre à jour chaque site à tout moment via un client FTP sécurisé grâce à des comptes dédiés (websgncom, websgnfr, websgneu). Chaque compte est isolé dans son propre répertoire et ne dispose pas d’accès SSH afin de limiter les risques de sécurité.
Plusieurs mécanismes de sécurité ont également été mis en place : activation du protocole HTTPS avec des certificats SSL/TLS auto-signés pour les trois domaines, ainsi que l’utilisation de connexions FTPS chiffrées en TLS 1.2 et TLS 1.3 pour les transferts de fichiers.
Un système complet de sauvegarde et de restauration automatisé a été déployé. Des sauvegardes locales quotidiennes sont réalisées sur le serveur, tandis qu’une copie externalisée est envoyée vers Google Drive via l’outil rclone. Ces opérations sont planifiées automatiquement grâce à des tâches cron.
La dernière étape du projet consiste à sécuriser les échanges entre le serveur web et le serveur de base de données distant, notamment par la mise en place d’un tunnel SSH ou d’un chiffrement TLS pour les connexions MySQL.
Partie Développement
Le pôle SLAM avait pour mission de poursuivre le développement de l’application web de gestion des frais du laboratoire GSB, déjà amorcée lors d’un projet précédent.
Dans un premier temps, le bon fonctionnement des fonctionnalités existantes a été vérifié. Cela a impliqué la mise en place de l’environnement de développement local sous WampServer, l’importation de la base de données dans phpMyAdmin, ainsi que la validation des fonctionnalités principales de l’application : connexion des utilisateurs, saisie des fiches de frais et enregistrement des données côté visiteurs médicaux.
Dans un second temps, la partie destinée au service comptable a été développée. Deux solutions conceptuelles ont été proposées afin de gérer la distinction entre les rôles visiteurs et comptables. La solution retenue repose sur l’ajout d’un attribut « rôle » dans la table utilisateur existante, permettant de différencier simplement les profils.
La base de données a été modifiée en conséquence et le système d’authentification a été adapté afin de rediriger chaque utilisateur vers l’interface correspondant à son rôle. Une interface spécifique au service comptable a également été développée et testée en local, permettant la consultation et la validation des fiches de frais.
L’ensemble du développement a été réalisé dans le respect de l’architecture MVC et des conventions de codage du projet, garantissant un code structuré, maintenable et évolutif.
L’application a ensuite été déployée sur le serveur Debian configuré par le pôle SISR, les identifiants d’accès ayant été transmis lors de la séance du 11 septembre.
Dans un premier temps, le bon fonctionnement des fonctionnalités existantes a été vérifié. Cela a impliqué la mise en place de l’environnement de développement local sous WampServer, l’importation de la base de données dans phpMyAdmin, ainsi que la validation des fonctionnalités principales de l’application : connexion des utilisateurs, saisie des fiches de frais et enregistrement des données côté visiteurs médicaux.
Dans un second temps, la partie destinée au service comptable a été développée. Deux solutions conceptuelles ont été proposées afin de gérer la distinction entre les rôles visiteurs et comptables. La solution retenue repose sur l’ajout d’un attribut « rôle » dans la table utilisateur existante, permettant de différencier simplement les profils.
La base de données a été modifiée en conséquence et le système d’authentification a été adapté afin de rediriger chaque utilisateur vers l’interface correspondant à son rôle. Une interface spécifique au service comptable a également été développée et testée en local, permettant la consultation et la validation des fiches de frais.
L’ensemble du développement a été réalisé dans le respect de l’architecture MVC et des conventions de codage du projet, garantissant un code structuré, maintenable et évolutif.
L’application a ensuite été déployée sur le serveur Debian configuré par le pôle SISR, les identifiants d’accès ayant été transmis lors de la séance du 11 septembre.
Situation d’avancement du projet
Dans le cadre du projet AP6, j’ai occupé le rôle de chef de projet au sein d’une équipe composée d’un développeur (pôle SLAM) et d’un administrateur systèmes et réseaux (pôle SISR). À ce titre, j’étais responsable de la planification du projet, de la coordination entre les équipes, du suivi des tâches via l’outil Kanboard et de la rédaction des comptes rendus hebdomadaires.
Étant en option SISR, j’ai également pris en charge l’ensemble des missions techniques liées à l’infrastructure. Cela incluait la reconstitution du serveur sous Debian 12, la configuration du serveur DNS Bind9, la mise en place d’un service FTPS sécurisé, l’activation du protocole HTTPS sur les trois domaines ainsi que le déploiement d’un système de sauvegarde automatisé à la fois local et externalisé dans le cloud.
Le projet s’est déroulé de fin août à début octobre 2025, avec des séances hebdomadaires donnant lieu à des comptes rendus détaillant les réalisations, les difficultés rencontrées et les priorités à venir. La coordination avec le pôle SLAM a été régulière et efficace : le déploiement de l’application dépendait directement de l’environnement serveur mis en place côté SISR, ce qui a nécessité une communication constante entre les deux équipes.
Avec le recul, je reconnais qu’une meilleure anticipation des délais aurait permis de finaliser le POC de sécurisation des échanges avec le serveur de base de données distante. Cette expérience m’a néanmoins permis de développer des compétences techniques solides en administration systèmes et réseaux, tout en renforçant ma capacité à piloter un projet en équipe dans un contexte professionnel réaliste.
Étant en option SISR, j’ai également pris en charge l’ensemble des missions techniques liées à l’infrastructure. Cela incluait la reconstitution du serveur sous Debian 12, la configuration du serveur DNS Bind9, la mise en place d’un service FTPS sécurisé, l’activation du protocole HTTPS sur les trois domaines ainsi que le déploiement d’un système de sauvegarde automatisé à la fois local et externalisé dans le cloud.
Le projet s’est déroulé de fin août à début octobre 2025, avec des séances hebdomadaires donnant lieu à des comptes rendus détaillant les réalisations, les difficultés rencontrées et les priorités à venir. La coordination avec le pôle SLAM a été régulière et efficace : le déploiement de l’application dépendait directement de l’environnement serveur mis en place côté SISR, ce qui a nécessité une communication constante entre les deux équipes.
Avec le recul, je reconnais qu’une meilleure anticipation des délais aurait permis de finaliser le POC de sécurisation des échanges avec le serveur de base de données distante. Cette expérience m’a néanmoins permis de développer des compétences techniques solides en administration systèmes et réseaux, tout en renforçant ma capacité à piloter un projet en équipe dans un contexte professionnel réaliste.
Partie Réseau
Reconstitution du serveur web GSB
À la suite du transfert du serveur physique vers un environnement virtualisé INTRALAB B (groupe 2), le serveur web du GSB a été reconstitué sous Debian 12, avec une adresse IP fixe 172.18.158.150 et le hostname InterlabB. Le service DHCP a été désactivé afin de configurer le réseau de manière statique.
Cette opération a impliqué l’installation et la configuration des services essentiels au fonctionnement des sites du laboratoire, notamment :
Cette opération a impliqué l’installation et la configuration des services essentiels au fonctionnement des sites du laboratoire, notamment :
- Apache2 pour l’hébergement et la diffusion des pages web.
- PHP pour le traitement dynamique des scripts.
- ProFTPD avec TLS afin d’assurer des transferts de fichiers sécurisés entre les développeurs et le serveur.
- Bind9 pour la gestion des noms de domaine au sein de l’infrastructure.
Mise en place de la liaison avec le serveur de base de données
La base de données ap5_BDMEDOCLABn est hébergée sur un serveur dédié distinct du serveur web afin d’assurer une meilleure sécurité et une isolation des données par rapport aux autres services.
Cette architecture permet de protéger les informations sensibles tout en améliorant la stabilité et les performances globales du système. Les paramètres de connexion ont été fournis sur demande afin de permettre au pôle SLAM d’établir la liaison entre l’application web et la base de données distante.
La sécurisation des échanges entre la plateforme web et le serveur de base de données distant constitue la dernière étape à finaliser avant la livraison du projet. Deux solutions sont envisagées : la mise en place d’un tunnel SSH ou l’utilisation d’un chiffrement TLS pour les connexions MySQL.
Un POC (Proof of Concept) démontrant la faisabilité de la solution sera réalisé et accompagné d’un schéma d’architecture afin de documenter l’implémentation retenue.
Cette architecture permet de protéger les informations sensibles tout en améliorant la stabilité et les performances globales du système. Les paramètres de connexion ont été fournis sur demande afin de permettre au pôle SLAM d’établir la liaison entre l’application web et la base de données distante.
La sécurisation des échanges entre la plateforme web et le serveur de base de données distant constitue la dernière étape à finaliser avant la livraison du projet. Deux solutions sont envisagées : la mise en place d’un tunnel SSH ou l’utilisation d’un chiffrement TLS pour les connexions MySQL.
Un POC (Proof of Concept) démontrant la faisabilité de la solution sera réalisé et accompagné d’un schéma d’architecture afin de documenter l’implémentation retenue.
Gestion des domaines
Le service DNS Bind9 a été installé et configuré afin d’assurer la résolution des trois domaines du laboratoire. Les sites sont ainsi accessibles via leurs noms de domaine plutôt que par l’adresse IP du serveur.
Les trois domaines pointent désormais correctement vers le serveur 172.18.158.150 et sont servis par Apache2 via des VirtualHosts dédiés. Chaque site dispose de son propre DocumentRoot ainsi que de fichiers de logs séparés afin de faciliter la gestion et le diagnostic des éventuels incidents.
- www.swiss-galaxyb.com
- www.swiss-galaxyb-france.fr
- www.swiss-galaxyb-europe.eu
named-checkzone, puis testée avec les outils dig et nslookup.Les trois domaines pointent désormais correctement vers le serveur 172.18.158.150 et sont servis par Apache2 via des VirtualHosts dédiés. Chaque site dispose de son propre DocumentRoot ainsi que de fichiers de logs séparés afin de faciliter la gestion et le diagnostic des éventuels incidents.
Mise à jour des sites
Pour permettre aux développeurs du pôle SLAM de mettre à jour les sites hébergés à tout moment, trois comptes FTP dédiés ont été créés et configurés :
La connexion FTPS a été testée et validée via FileZilla, avec certificat TLS et authentification réussie.
- websgncom → /var/www/swiss-galaxyb.com
- websgnfr → /var/www/swiss-galaxyb-france.fr
- websgneu → /var/www/swiss-galaxyb-europe.eu
La connexion FTPS a été testée et validée via FileZilla, avec certificat TLS et authentification réussie.
Sécurisation du serveur web
Le protocole HTTPS a été activé sur les trois domaines du laboratoire via le module SSL d’Apache2 (
Les connexions sont désormais chiffrées, bien que le navigateur affiche un avertissement lié au certificat auto-signé, celui-ci n’étant pas émis par une autorité de certification reconnue.
a2enmod ssl). Un certificat auto-signé a été généré avec OpenSSL (RSA 2048 bits, algorithme RSA-SHA256) avec les informations suivantes :
- CN : www.swiss-galaxyb.com
- Organisation : Galaxy Swiss Bourdin
- Localité : Saint-Denis, La Réunion
- Protocole : TLS 1.3 — Chiffrement : AES-256-GCM
Les connexions sont désormais chiffrées, bien que le navigateur affiche un avertissement lié au certificat auto-signé, celui-ci n’étant pas émis par une autorité de certification reconnue.
Répartition de charges
La mise en place d’une solution de répartition de charges n’a pas été réalisée dans le cadre de ce projet faute de temps. Cette mission, considérée comme un objectif avancé, aurait impliqué l’ajout d’un second serveur web identique ainsi que la configuration d’un outil tel que HAProxy, Corosync ou Pacemaker afin d’assurer la haute disponibilité et la répartition du trafic.
Un POC (Proof of Concept) démontrant la faisabilité de cette architecture était initialement prévu mais n’a pas pu être finalisé. Avec le recul, une meilleure anticipation des délais aurait permis d’aborder cette partie. Cela constitue néanmoins un axe d’amélioration identifié pour de futurs projets similaires.
Un POC (Proof of Concept) démontrant la faisabilité de cette architecture était initialement prévu mais n’a pas pu être finalisé. Avec le recul, une meilleure anticipation des délais aurait permis d’aborder cette partie. Cela constitue néanmoins un axe d’amélioration identifié pour de futurs projets similaires.
Sécurisation des échanges
Dans le cadre du projet, la sécurisation des échanges entre la plateforme web et le serveur de base de données distant constituait un enjeu important afin de garantir la confidentialité et l’intégrité des données transmises.
L’objectif était de protéger les communications entre les différents composants de l’infrastructure, notamment lors des échanges entre l’application web et la base de données hébergée sur un serveur distant.
Un Proof of Concept (POC) devait être réalisé afin d’évaluer la faisabilité technique de cette sécurisation et de comparer différentes solutions telles que le tunnel SSH, l’utilisation d’un VPN ou encore le chiffrement via TLS.
Ces travaux s’inscrivaient dans une démarche d’amélioration de la sécurité globale du système d’information. Ils représentaient également un approfondissement technique permettant d’explorer des solutions avancées en matière de sécurisation des infrastructures.
L’objectif était de protéger les communications entre les différents composants de l’infrastructure, notamment lors des échanges entre l’application web et la base de données hébergée sur un serveur distant.
Un Proof of Concept (POC) devait être réalisé afin d’évaluer la faisabilité technique de cette sécurisation et de comparer différentes solutions telles que le tunnel SSH, l’utilisation d’un VPN ou encore le chiffrement via TLS.
Ces travaux s’inscrivaient dans une démarche d’amélioration de la sécurité globale du système d’information. Ils représentaient également un approfondissement technique permettant d’explorer des solutions avancées en matière de sécurisation des infrastructures.
Partie Développement
Vérification des fonctionnalités existantes
La première étape du projet consistait à vérifier le bon fonctionnement de la saisie et de l’affichage des fiches de frais destinées aux visiteurs médicaux.
Cette phase de validation impliquait de tester l’interface utilisateur existante, de contrôler l’enregistrement correct des données dans la base de données et de s’assurer que les utilisateurs pouvaient consulter leurs fiches de frais sans erreurs ni incohérences.
Ces tests avaient pour objectif de garantir la stabilité et la fiabilité des fonctionnalités déjà en place avant d’entamer les développements complémentaires.
Cette phase de validation impliquait de tester l’interface utilisateur existante, de contrôler l’enregistrement correct des données dans la base de données et de s’assurer que les utilisateurs pouvaient consulter leurs fiches de frais sans erreurs ni incohérences.
Ces tests avaient pour objectif de garantir la stabilité et la fiabilité des fonctionnalités déjà en place avant d’entamer les développements complémentaires.
Développement de la partie “Service comptable”
Une fois les fonctionnalités existantes validées, il a été nécessaire de développer la partie “Service comptable” de l’application.
Cette nouvelle section avait pour objectif de permettre aux comptables de consulter, contrôler et valider les fiches de frais soumises par les visiteurs médicaux.
Le développement s’est appuyé sur des cas d’utilisation détaillés, définis en amont, afin de garantir la conformité fonctionnelle de la solution avec les besoins métiers.
Une attention particulière a été portée à la gestion des différents états des fiches de frais (en attente, validée, refusée, etc.), ainsi qu’au processus de validation, permettant d’assurer une traçabilité complète et une cohérence dans le suivi des remboursements.
Cette nouvelle section avait pour objectif de permettre aux comptables de consulter, contrôler et valider les fiches de frais soumises par les visiteurs médicaux.
Le développement s’est appuyé sur des cas d’utilisation détaillés, définis en amont, afin de garantir la conformité fonctionnelle de la solution avec les besoins métiers.
Une attention particulière a été portée à la gestion des différents états des fiches de frais (en attente, validée, refusée, etc.), ainsi qu’au processus de validation, permettant d’assurer une traçabilité complète et une cohérence dans le suivi des remboursements.
Mise en ligne de l’application
Après la phase de développement en environnement local, l’application a été déployée sur le serveur de production afin d’être accessible aux utilisateurs finaux.
Cette étape a consisté à migrer l’ensemble du projet, à vérifier les dépendances nécessaires et à adapter les configurations pour garantir un fonctionnement optimal dans un environnement réel.
Une attention particulière a été portée au respect de l’architecture MVC (Modèle – Vue – Contrôleur), afin d’assurer un code structuré, maintenable et évolutif.
Cette organisation permet de faciliter les futures évolutions de l’application tout en garantissant sa stabilité et sa pérennité.
Cette étape a consisté à migrer l’ensemble du projet, à vérifier les dépendances nécessaires et à adapter les configurations pour garantir un fonctionnement optimal dans un environnement réel.
Une attention particulière a été portée au respect de l’architecture MVC (Modèle – Vue – Contrôleur), afin d’assurer un code structuré, maintenable et évolutif.
Cette organisation permet de faciliter les futures évolutions de l’application tout en garantissant sa stabilité et sa pérennité.
Partie Juridique
Qualification juridique des informations contenues dans la base de données
Les informations contenues dans la base de données du laboratoire Galaxy Swiss Bourdin concernent principalement les visiteurs médicaux et les comptables : nom, prénom, identifiant, adresse e-mail, montant des frais, trajets effectués, justificatifs de dépenses, etc.
Ces informations sont qualifiées de données à caractère personnel au sens de l’article 4 du Règlement Général sur la Protection des Données (RGPD), car elles permettent d’identifier directement ou indirectement une personne physique, même dans un cadre professionnel.
Elles sont donc soumises aux obligations légales en matière de protection des données personnelles et doivent être traitées conformément aux règles de sécurité, de confidentialité et de minimisation prévues par la réglementation européenne.
Base juridique du recueil des informations et nécessité du consentement
Le recueil des données s’effectue dans un cadre strictement professionnel. Les visiteurs médicaux et les comptables saisissent leurs informations sur le site intranet de l’entreprise afin de permettre au service comptabilité de gérer les remboursements des frais de déplacement.
Les données collectées (identité, montants des frais, justificatifs) sont nécessaires pour exécuter le contrat de travail et respecter les obligations légales et comptables de l’entreprise.
La base juridique du traitement repose sur la nécessité d’exécution du contrat, conformément à l’article 6 du Règlement Général sur la Protection des Données (RGPD). Le consentement préalable des utilisateurs n’est donc pas requis, car le traitement découle directement des obligations liées à la relation de travail.
Les personnes concernées doivent toutefois être informées de la finalité du traitement ainsi que des modalités de gestion et de protection de leurs données personnelles.
Les données collectées (identité, montants des frais, justificatifs) sont nécessaires pour exécuter le contrat de travail et respecter les obligations légales et comptables de l’entreprise.
La base juridique du traitement repose sur la nécessité d’exécution du contrat, conformément à l’article 6 du Règlement Général sur la Protection des Données (RGPD). Le consentement préalable des utilisateurs n’est donc pas requis, car le traitement découle directement des obligations liées à la relation de travail.
Les personnes concernées doivent toutefois être informées de la finalité du traitement ainsi que des modalités de gestion et de protection de leurs données personnelles.
Principales règles applicables au traitement des informations
Le traitement des données du laboratoire GSB doit respecter les principes fondamentaux du Règlement Général sur la Protection des Données (RGPD) :
- Licéité, loyauté et transparence : le traitement doit reposer sur une base légale et les salariés doivent être informés de la finalité de l’utilisation de leurs données.
- Finalité déterminée : les données collectées ne peuvent être utilisées que pour la gestion des frais professionnels.
- Minimisation des données : seules les informations strictement nécessaires au traitement doivent être collectées.
- Exactitude : les données doivent être exactes et mises à jour si nécessaire.
- Limitation de la conservation : les données ne doivent pas être conservées au-delà de la durée légale de conservation comptable.
- Sécurité et confidentialité : des mesures techniques doivent être mises en place, telles que le chiffrement SSL/TLS, l’utilisation de mots de passe sécurisés et la mise en place de sauvegardes automatisées.
- Droits des personnes : les salariés peuvent exercer leurs droits d’accès, de rectification ou de suppression de leurs données.
- Responsabilité (accountability) : le laboratoire doit être en mesure de démontrer à tout moment le respect de ces règles.
Protection de la base de données par le droit d’auteur
Une base de données peut être protégée par le droit d’auteur uniquement si sa structure ou son organisation résulte d’une création intellectuelle originale.
Dans le cas du laboratoire GSB, la base de données est construite à partir d’un modèle logique et fonctionnel permettant de gérer les fiches de frais, les utilisateurs et les justificatifs. Cette organisation repose principalement sur des critères techniques liés au fonctionnement de l’application.
La structure de la base ne présente donc pas de caractère d’originalité suffisant pour être protégée par le droit d’auteur. Elle ne remplit pas les conditions juridiques nécessaires pour bénéficier de cette protection.
Autre régime de protection applicable : le droit sui generis des bases de données
Bien que la base de données ne bénéficie pas de la protection par le droit d’auteur, elle peut être protégée par le droit sui generis du producteur de base de données, prévu par les articles L341-1 et suivants du Code de la propriété intellectuelle.
Ce droit protège le laboratoire GSB en tant que producteur ayant investi de manière substantielle dans la constitution, la vérification et la présentation de la base de données.
Il permet au laboratoire d’interdire à tout tiers l’extraction ou la réutilisation non autorisée d’une partie substantielle du contenu de la base.
Compétences mobilisées – Bloc 1
Dans le cadre du projet GSB, j’ai mobilisé plusieurs compétences du bloc 1, notamment en tant que chef de projet et intervenant technique sur la partie SISR. Ces compétences ont été mises en œuvre à travers les différentes phases du projet, allant de la mise en place de l’infrastructure jusqu’à la sécurisation et au déploiement de l’application.
- B1.1 – Gérer le patrimoine informatique : J’ai vérifié les conditions de continuité du service en mettant en place un serveur web fiable sous Debian 12, accompagné de mécanismes de sauvegarde automatisés (local et externalisé avec rclone). J’ai également veillé au respect des bonnes pratiques de sécurité, notamment avec l’isolation des comptes FTP, l’utilisation du HTTPS et la limitation des accès SSH.
- B1.2 – Répondre aux incidents et aux demandes d’assistance et d’évolution : J’ai été amené à diagnostiquer et corriger des problèmes liés à la configuration des services (Apache, DNS, FTPS) et à adapter l’infrastructure pour répondre aux besoins du projet, notamment pour permettre le déploiement de l’application par le pôle SLAM et assurer la communication avec la base de données distante.
- B1.3 – Développer la présence en ligne de l’organisation : J’ai contribué à la mise en ligne des sites web du laboratoire GSB en configurant les domaines, les VirtualHosts Apache et le serveur DNS Bind9. Cela a permis de rendre les applications accessibles via des noms de domaine clairs et professionnels.
- B1.4 – Travailler en mode projet : En tant que chef de projet, j’ai assuré la planification des tâches, le suivi de l’avancement via Kanboard et la coordination entre les pôles SISR et SLAM. J’ai également organisé les échanges et veillé au respect des délais tout au long du projet.
- B1.5 – Mettre à disposition des utilisateurs un service informatique : J’ai participé à la mise en production de l’application en garantissant un environnement fonctionnel, sécurisé et stable. Des tests ont été réalisés pour valider le bon fonctionnement des services (web, FTP, DNS) avant leur mise à disposition aux utilisateurs.
- B1.6 – Organiser son développement professionnel : Ce projet m’a permis de développer mes compétences techniques en administration systèmes et réseaux (Debian, Apache, Bind9, sécurité) ainsi que ma capacité à travailler en autonomie et à documenter mes réalisations dans un contexte professionnel.