PLANET Bourgogne

Présentation de l'organisation

• Adresse

• Site web

Lien

• Généralités

• Domaine d'activités : Entreprise de Services Numériques
• Historique :
1995
PLANET Bourgogne débute son activité de Fournisseur d’Accès à Internet dans le Parc Technologique dijonnais de la Toison d’Or, rue Louis de Broglie.
2000
L’entreprise collabore désormais avec Pierre et Vacances après que ce dernier ait racheté Maeva. Cela influera sur sa volonté de se spécialiser dans la fourniture de prestations informatiques dont l’infogérance. L’entreprise déménage rue Stalingrad (Z.A.E. Cap Nord) à Dijon l’année suivante.
2007
Déménagement rue de la Redoute (Z.A.E. Cap Nord), à Saint-Apollinaire, construction d'une salle d'hébergement à très haut niveau de sécurité et de disponibilité.
2020
Création, en collaboration avec plusieurs entreprises, du premier Datacenter de proximité de Bourgogne: DTiX.
• Effectif : 22 personnes

• Système d'informations

• Importance stratégique : PLANET Bourgogne doit assurer la continuité des services qu'elle propose à ses clients via un service d'astreinte afin que ceux-ci souffrent de moins de temps d'interruption possible. En effet, tout arrêt entraîne des coûts financiers chez ceux-ci (perte de ventes potentielles notamment), c'est pourquoi une attention particulière est portée afin d'éviter tout dysfonctionnement.
• Services de l'organisation :
Hébergement et infogérance
Ce service propose l'hébergement et la maintenance d'espaces d'hébergement web, messagerie, bases de données en fonction des besoins des clients. Différents types d'interventions sont proposés tels que la supervision (heures ouvrées et/ou non ouvrées), des tests de charge, de sécurité, notamment.
Développement de solutions applicatives web et mobile
PLANET Bourgogne propose également à ses clients des solutions applicatives web ou sur support mobile. Celles-ci sont entièrement personnalisables et construites de A à Z en fonction du besoin de ses clients. Il s'agit ici de proposer un service 100% personnalisé et non un modèle identique personnalisable à tous ses clients.
Administratif

• Service d'accueil : Hébergement et infogérance

• Type de tâches sous la responsabilité du service :
• Gestion d'incidents
• Maintenance d'équipements et d'espace clients
• Gestion de projet
• Gestion commerciale
• Support client

Travail effectué

• Deux ans d'alternance (Responsable en Ingénierie Système et Réseau, diplôme Bac+4, CESI Dijon)
• Six mois en tant que Technicien Sytème et Réseau
Durant mes deux ans d'alternance, j'ai pu évoluer dans des projets avec l'entraide de l'équipe qui m'a accueili. J'ai beaucoup appris, que ce soit en réalisant des opérations, des migrations ou en observant le travail de mes collègues. Cela m'a permis d'obtenir de nouvelles compétences, et quelques nouvelles notions. Ayant travaillé presque exclusivement du côté des postes de travail client, cette alternance m'a permis de découvrir les opérations autour de la messageries, des sites web ou DNS, sujets sur lesquels j'avais travaillés de façon théorique durant mon parcours formatif.
J'ai réalisé dans le cadre de cette formation un mémoire portant sur la "Migration d'un Plan de Reprise d'Activités", qui n'est pas accessible pour des raisons de confidentialité.
Durant mon travail de technicien, je me suis davantage axé sur les demandes courantes liées à la messagerie et aux sites web des clients.
• Migration de serveurs web, AD, GED, PRA
• Support client (messagerie, web)
• Résolution d'incidents et communication client
• Réservation et mise en place de certificats SSL
• Maintenance et évolutibilité de l'outil de supervision
Retour

Maincare Solutions

Présentation de l'organisation

• Implentation



• Site web

Lien

• Généralités

• Domaine d'activités : Editeur de logiciels de santé
• Effectif : 700 personnes
• Importance stratégique du système d'informations Etant donné que Maincare est positionné sur le secteur d'informatique de santé, les services qu'elle fournit à ses clients sont critiques, car ils impactent directement le bon fonctionnement des hôpitaux. C'est pourquoi elle dispose d'un ser vice d'asteinte veillant à ce que les rendez-vous et la gestion des admissions, par exemple, puissent être fonctionnel 24h/24 7j/7, les hôpitaux ne fermant jamais. Elle doit également veiller à une sécurité irréprochable, notamment au niveau des sauvegardes. S'agissant de données médicales, elles ont une durée de conservation beaucoup long et un besoin d'intégrité beaucoup plus important. C'est en ce sens que Maincare est certifié Hébergeur de données de santé et suit à ce titre un nombre conséquent de bonnes pratiques.

• Service d'accueil : Hébergement Cloud Santé

Ce service supervise l'installation et la maintenance des serveurs qu'elle héberge. Déploiement, mise à jour, gestion des incidents, sont autant de rôles gérés par celui-ci.

Travail effectué

• Reponsable de la CMDB : Alimentation et mise en forme des données d'inventaire liées aux serveurs
• Déploiement de plateformes : Attribution des ressources et déploiement automatisé des serveurs

Pour mener à bien mes missions, j'ai développé des fichiers Excel via Powerquery afin de simplifier de nombreuses opérations, comme par exemple le contrôle du bon remplissage de la CMDB, ou encore la génération de scripts de déploiement de machines. Cela m'a permit de limiter le risque d'erreur lié au remplissage manuel et une vérification plus simple, plus poussée et beaucoup plus rapide. Cela a permis un gain de productivité important.

En dehors de ces rôles, j'ai été amené à me rendre compte du fonctionnement d'une société de plus grande envergure que mon poste précédent. De cette expérience, j'ai beaucoup appris sur le fonctionnement de la communication entre les différents services, et de l'intérêt de connaîtres les rôles et responsabilités de chacun d'entre eux.

Cela m'a également permis de connaître un peu mieux le monde de la santé ainsi que ses usages.

Retour

Hôtel de ville de Troyes - Gestion de parc

Présentation de l'organisation

• Généralités

• Dénomination sociale : Hôtel de ville de Troyes
• Domaine d'activités : Territorial
• Historique : Construit de 1624 à 1672 (arrêt des travaux pour manque d’argent entre 1624 et 1670)
• Structure organisationnelle

• Système d'informations

• Importance stratégique : La mairie de Troyes gère de nombreux “services” tels que les écoles, la communauté d'agglomération Troyes Champagne Métropole ou encore certaines communes. Il est ainsi important de garantir la disponibilité du matériel et du réseau pour que les fonctionnaires puissent travailler. C’est pour cela qu’un système d'astreinte a été mis en place pour pouvoir corriger une panne en urgence, même la nuit.
• Organisation : La DSI s’organise autour de deux pôles : le pôle gestion de parc (gestion du matériel et du réseau) et le pôle téléphonie
• Effectif : 7 personnes travaillent au service de la gestion de parc

• Service d'accueil : Pôle Gestion de parc de la DSI - Hôtel de ville de Troyes

• Type de tâches sous la responsabilité du service :
• Participer à la maintenance du système d'information
• Renouveller régulièrement le parc informatique et participer à son installation
• Administrer le réseau (sauvegarde, gestion de parc...)
• Répondre aux demandes d'assistance du personnel
• Résoudre les incidents signalés sur le réseau, éventuellement en prenant la main à distance quand cela est possible.
• Matériel à disposition : Ordinateurs fixes et portables (Fujitsu, HP, Terra en fonction d’un appel d’offre), serveurs, switchs, éléments d'interconnexion, imprimantes, scanners, câbles divers, clavier, souris, écrans, téléphones, tablettes, vidéoprojecteurs, vidéoprojecteurs interactifs, scanner de code-barres (utilisé en grande partie pour GLPI)
• Place dans l'organigramme

Travail effectué

Projet professionnel

• Présentation du projet : Restructuration du parc informatique. Etiquettage du matériel informatique avec un code-barres du numéro d'inventaire crée lors du projet
• Aide à la génération d'étiquettes doté de code-barres pour coller sur le matériel et génération de documentation portant sur l'utilisation du logiciel pour les techniciens informatiques
• Production d'un document CSV qui convertit le nom long collé sur l'étiquette en numéro d'inventaire avec une macro permettant de copier le code obtenu. Ceci permettera aux employés de recopier les informations que liront sur l'étiquette de leur poste les usagers qui demandent de l'aide, et de copier le code converti pour le coller dans GLPI et retrouver le matériel incriminé.
• Inventaire : Déballage de matériel neuf et déplacement à la cave de tout le matériel neuf après étiquettage (code-barres). Recyclage des matériaux d'emballage. Tri du matériel en fonction des entités (TCM, ville et médiathèque) et du statut (matériel de retour, stock occasion et neuf a préparer ou prêts). Etiquettage du matériel utilisé par les employés de la DSI.

  Au total, nous avons dû gérer 360 équipements, dont :

  • 143 ordinateurs (137 ordinateurs fixes (dont 85 neufs) et 6 ordinateurs portables neufs
  • 23 imprimantes (dont 13 neufs)
  • 191 écrans (dont 47 neufs)
  • 3 vidéoprojecteurs d'occasion


Matériel neuf déballé et étiquetté

Matériel neuf déballé et étiquetté

Matériel neuf déballé et étiquetté
Précédent Suivant

Missions annexes

• Installation de matériel informatique : branchement de postes, installation d'un télécopieur sur les postes d'un service
• Recherche de solutions pour répondre aux besoins : étude d'une fonctionnalité de TightVNC (documentation) , d'un moyen de réutiliser les licences Office de postes hors service sur lesquels le logiciel n'a pas pu être desinstallé
• Démontage de 10 tableaux blancs interactifs dans 2 écoles et aide à l'installation des vidéo-projecteurs interactifs les remplaçant
• Prise en charge de demande d'assistance et d'incident. Diagnotic, proposition de solution et remplacement de matériel
• Test de fonctionnement de câbles et périphériques avec utilisation d'un testeur RJ45

Compétences mises en oeuvre

D 1.3 Mise en production d'un service
A 1.3.1 Test d'intégration et acceptation d'un service
A 1.3.3 Accompagnement de la mise en place d'un nouveau service
D 2.2 Gestion des incidents et demandes d'assistance
A 2.2.1 Suivi et résolution d'incidents'
D 3.2 Installation d’une solution d'infrastructure
A 3.2.1 Installation et configuration d'éléments d’infrastructure
A 3.2.2 Remplacement ou mise à jour d’éléments défectueux ou obsolètes
D4.1 Conception et réalisation d'une solution applicative
A 4.1.9 Réalisation d'une documentation technique
D 5.1 Gestion des configurations
A 5.1.1 Mise en place d’une gestion de configuration
A 5.1.2 Recueil d'informations sur une configuration et ses éléments
A 5.2.4 Etude d’une technologie, d’un composant, d’un outil ou d’une méthode

Bilan

Apports pour l'organisme

• Aide apportée au personnel pour étiqueter du matériel ou rechercher des solutions techniques
• Aide aux usagers
• Mise en place des modèles d'étiquettes et des fichiers de création du numéro d'inventaire en fonction des services grâce à un modèle déjà créé

Apports personnels



• Découverte d'une organisation et de l'articulation entre les différents services gérés par le pôle gestion de parc
• Découverte du cycle de vie d'un matériel et de son processus, de son achat à sa mise au rebut
• Prise en considération de l'importance du systèmes d'informations de la mairie et de sa disponiblité permanante (astreinte, support technique)
• Importance de trier correctement le matériel, de renseigner le plus d'informations possibles (éviter les doublons GLPI), et d'assurer un suivi rigoureux du matériel
• Tâches régulièrement effectuées par le personnel du service (installation, configuration...)
• L'inventaire représente l'une des tâches fastidieuses que doivent réaliser tous les techniciens réseaux.

• Compétences :

• Quelques opérations de brassage de câble
• Rigueur dans l'inventaire, l'étiquettage et l'ajout d'un numéro d'inventaire
• Test de fonctionnement, démontage et nettoyage d'ordinateurs
• Installer et désinstaller des machines
• Installation et mise à jour de postes

Retour

PPE 1

Restaurant Lucien Doriath

Contexte

Le restaurant Lucien Doriath est une Société anonyme spécialisée dans la restauration à base de foie gras de canard à Soultz-les-Bains (67) depuis plus de 20 ans. Cet établissement sert à la fois de restaurant, lieu de production et boutique de foie gras.

Besoins

• Permettre à un accès Internet aux clients
• Disposer d’un site comportant les réservations ainsi que toutes les informations connexes utiles au personnel

Situation actuelle

Le restaurant dispose d’un site Internet qui permet de réserver un repas ou encore d’acheter des produits culinaires à base de foie gras, en ligne. Il propose également des cours de cuisine.

Solutions mises en place

• Création d’un site intranet comportant des éléments suivants :
• Liste des réservations à confirmer (une semaine à l’avance)
• Liste des menus réservés le surlendemain, afin d’acheter les ingrédients
• Liste des réservations pour le lendemain, afin d’organiser l’organisation de la salle
• Création d’une application regroupant les statistiques

Compétences développées

Analyse de la demande
A 1.1.1 : Analyse du cahier des charges
A 1.1.2 : Etude de l’impact de l’intégration d’un service sur le système informatique
Mise en production d’un service
A 1.3.1 : Test d’intégration et d’acceptation d’un service
A 1.3.3 : Accompagnement de la mise en place d’un nouveau service
Travail en mode projet
A 1.4.1 : Participation à un projet
A 1.4.2 : Evaluation des indicateurs de suivi d’un projet et justifications des écarts
A 1.4.3 : Gestion des ressources
Conception d’une solution d’infrastructure
A 3.1.2 : Maquettage et prototypage d’une solution d’infrastructure
Conception et réalisation d’une solution applicative
A 4.1.2 : Conception ou adaptation de l’interface utilisateur d’une solution applicative
A 4.1.7 : Développement, utilisation ou adaptation de composants logiciels
A 4.1.9 : Rédaction d’une documentation technique
A 4.1.10 : Rédaction d’une documentation utilisateur

Retour

PPE 2

Laboratoire GSB

Contexte

Le laboratoire Galaxy Swiss Bourdin (GSB) est issu de la fusion entre Galaxy (maladies virales comme le SIDA) et Swiss-Bourdin (médicaments plus conventionnels). Il est le leader du marché pharmaceutique.

Besoins

Le laboratoire souhaite uniformiser la gestion du suivi des visites, fournir des logiciels aux visiteurs afin qu’ils puissent répondre aux attentes de leurs clients, en fournissant notamment des informations complémentaires sur les médicament par le biais d’une application. Les compte-rendus des visiteurs ne parviennent pas au siège du groupe, ou d’une manière jugée trop lente. Il faut donc envisager des envois plus rapides, de manière directe.

Par conséquent, GSB nécessite le développement d’une application de présentation des médicaments ainsi que d’une nouvelle application web permettant de centraliser les compte-rendus effectués par les visiteurs, avec une possibilité de générer des statistiques.

Situation actuelle

L’entreprise dispose déjà d’un parc informatique important, centralisé au 6ème étage de son siège parisien. Tous les dispositifs de sécurité et de tolérance de pannes sont déjà opérationnels.

Cependant, les équipes étant malmenées par cette fusion, l’objectif pour l’entreprise est donc de leur redonner confiance, tout en améliorant la gestion du suivi des visiteurs médicaux.

Les visiteurs médicaux sont des personnes chargées est de présenter des médicaments aux professionnels de santé, que ceux-ci pourraient prescrire à leurs clients. Ils ne font aucune vente, se contentant d’une simple présentation à but informative.

Solutions mises en place

• Installation d’une machine virtuelle VirtualBox sur un serveur distant
• Installation d’un dokuwiki sur cette machine virtuelle afin d’y consigner la documentation concernant le projet (avancement, solutions techniques apportées…)
• Mise en place de crontab permettant l’allumage et l’extinction automatique de la machine virtuelle durant les horaires de travail.
• Mise en place d’une sauvegarde automatique de la base de données utilisée par les développeurs et stockée sur le serveur.
• Changement de système de virtualisation, transfert des données de la machine virtuelle vers un conteneur Proxmox.

Captures d'écran du projet

Activités du réferentiel mises en oeuvre

Analyse de la demande
A 1.1.1 : Analyse du cahier des charges
A 1.1.2 : Etude de l’impact de l’intégration d’un service sur le système informatique
A1.1.3 : Étude des exigences liées à la qualité attendue d’un service
Mise en production d’un service
A 1.3.1 : Test d’intégration et d’acceptation d’un service
A 1.3.3 : Accompagnement de la mise en place d’un nouveau service
Travail en mode projet
A 1.4.1 : Participation à un projet
A 1.4.2 : Evaluation des indicateurs de suivi d’un projet et justifications des écarts
A 1.4.3 : Gestion des ressources
Installation d’une solution d’infrastructure
A 3.2.2 : Remplacement ou mise à jour d’éléments défectueux ou obsolètes (migration)
Administration et supervision d’une infrastructure
A 3.3.1 Administration sur site ou à distance des éléments d’un réseau, de serveurs, de services et d’équipements terminaux
A 3.3.2 Planification des sauvegardes et gestion des restaurations
A 3.3.4 Automatisation des tâches d’administration

Fermer le projet

PPE 3

SDIS29

Contexte

SDIS, Services Départementaux d’Incendie et de Secours représente l'une des compétences de la Direction de la Sécurité Civile, gère les accidents quotidiens et les catastrophes (aide à la population) Elle intervient rapidement sur les lieux d’un incident, et utilise donc l'outil informatique pour disposer d'informations en temps réél.

Besoins

• Rendre plus rapide la mobilisation des pompiers volontaires

Dès le déclenchement des alertes, ils doivent recevoir une un appel dans l’immédiat et rejoindre au plus vite le centre de secours. L’application devra privilégier les pompiers disponibles, et seulement après envisager d’appel de pompiers au travail et mémoriser les coordonnées des employeurs des pompiers volontaire afin qu'ils puissent justifier leur absence au travail.

• Meilleure gestion des effectifs des pompiers volontaires

Un pompier dépend d'une caserne, dans laquelle il y a un chef de caserne et un responsable d’alerte L'application affiche ainsi les informations et disponibilité des pompiers selon le calendrier des gardes émis par les chefs de centre. Elle permet de mieux connaître qui est disponible et de les appeller immédiatement.

• Différents types de comptes utilisateurs, différents droits

• Chef de centre : Créer, modifier et visualiser profils pompiers
• Pompier volontaire : Afficher et modifier ses infos persos
• Responsable d’alerte : Mobiliser les pompiers volontaires [réalisée par la suite]

Solutions mises en place

• Mise en place des serveurs

• Création d'une machine virtuelle Proxmox sur laquelle sont stockés deux conteneurs : un conteneur de test et un conteneur de production
• Sur le conteneur de test : création d’un dépôt GIT accessible à distance avec la commande git init sdis29.git --bare --shared , test de fonctionnement avec la commande git clone
• Installation et configuration du serveur Tomcat, qui nous permettra de faire fonctionner l’application web. Pour ce faire, ajout d’un hook “post-receive” dans le dépôt git. Cela copie tous les fichiers du dépôt dans le dossier utilisé par Tomcat8 (/var/lib/tomcat8/webapps) à chaque fois qu'un git push est réalisé afin que l’application soit accessible depuis le réseau.
• Création d’un Dokuwiki utilisé pour organiser notre travail

• Supervision Icinga

• Objectif : Vérifier que les services restent accessibles et fonctionnels, et anticiper et réparer rapidement les problèmes
• Création d'une machine virtuelle apellée Icinga sur un poste physique
• Machines supervisées : conteneur de test, conteneur de production, machine virtuelle Proxmox, serveur physique contenant la machine virtuelle, commutateur, passerelle
• Services supervisés : SSH, ping pour tous les serveurs, ainsi que la charge CPU, l'occupation mémoire, l'espace disque restant, le débit réseau, l'accessibilité web (HTTP) et le fonctionnement du serveur Tomcat sur les conteneurs où sont stockés l'application (de test et de production).
• Envoi de mails en cas d'incidents à tous les membres de l'équipe de travail. Pour cela, nous avons dû installer et configurer Postfix sur la machine virtuelle Icinga.
• Gestion des dépendances : Cela signifique que le fonctionnement d'une machine dépend de la machine qui l'heberge ou duquel elle dépend. Les indiquer dans les fichiers de configurations Icinga nous permet d'éviter de recevoir de nombreux mails si un serveur physique comportant de nombreuses machines virtuelles supervisées cessent de fonctionner.

• Gestion des logs

Les logs de tous les serveurs ainsi que du commutateur sont renvoyés sur une machine virtuelle

• Objectif : Pouvoir observer les logs sur une même machine et pouvoir détecter plus rapidement l’origine d’un incident
• Modification des fichiers de configuration de rsyslog sur les serveurs afin que les logs soient renvoyés sur la machine
• Mise en place d'une rotation des logs (rotation hebdomadaire sur 4 semaines) afin que les fichiers de logs plus anciens soient compressés et que tout ne reste pas dans le même fichier (découpage des logs). Cela permet de vérifier le stockage restant ainsi que de s'y trouver une information plus facilement.
• Vérification que les synchronisations temporelles des machines fonctionnent correctement.

• Déploiement d’un poste de travail

• Création d'une machine virtuelle "depl" sur une machine physique
• Objectif : SDIS29 souhaite déployer de nouveaux ordinateurs et souhaiterait le faire de manière automatique grâce à un logiciel de déploiement afin de gagner du temps. Le faire manuellement serait trop long, trop fastidieux et source d'erreurs.
• Choix de l'application : Après rédaction d'un document de choix technique, nous avons choisi d'utiliser Fog, que j'avais déjà utilisé avec un membre de l'équipe lors de mon stage de première année
• Installation de Fog, et changement du mot de passe de la base de données créée par Fog, qui était vide, pour plus de sécurité
• Création d'une image master depuis une machine virtuelle Windows XP et importation de celle-ci sur le serveur
• Déploiement de celle-ci sur une machine virtuelle

• Sécurité et sauvegarde de l’application

• Objectif : sécuriser les accès à la machine contenant l’application et sauvegarder régulièrement la base de données
• Mise au point d’un script de sauvegarde et d’un script de restauration de la base de données
• Modification des fichiers du configuration du démon sshd afin qu’ils ne permettent plus d'accéder à la machine contenant l’application en entrant un couple utilisateur/mot de passe.
  Ainsi, seules les machines possèdant un couple de clé publique/privée sont autorisées à se connecter aux serveurs, et non n'importe qui sur le réseau
• Mise en place d'un certificat HTTPS sur le Dokuwiki afin de sécuriser les pages web, avec redirection obligatoire des accès HTTP sur HTTPS
• Installation d'un HIDS, AIDE, qui compare tous les jours tous les fichiers avec leur somme unique générée la veille. Le but est de vérifier que les fichiers sensibles statiques ne varient pas à notre insu, ce qui pourrait être synonyme d'une intrusion.
• Installation du dispositif fail2ban, qui bannit un trop grand nombre de tentatives de connexions SSH, avec de mauvais identfiants, afin d'éviter les piratages par force brute notamment
• Mise en place d'un pare-feu bloquant tous les accès sauf ceux dont nous nous servons. La connexion au site et aux serveurs ne se fait que depuis le réseau interne (HTTP, ping, DNS, tomcat) et toutes les connexions sortantes initiées depuis le réseau interne sont autorisées
• Création d'un fichier goss permettant de vérifier la bonne configuration des serveurs (les démons Tomcat, MySQL, Apache sont bien actifs et leur port est ouvert, test de ping...)

• Automatisation de l'installation des serveurs avec Ansible

• Objectif : pouvoir réinstaller rapidement les serveurs de test et de production en cas de panne grâce à des playbooks Ansible
• Un premier playbook ppebase.yml ,qui installe le gestionnaire de bases de données MariaDB et le serveur Tomcat
• Un deuxième playbook ppedb.yml , qui créé la base de données, les comptes MariaDB, et importe le script d'importation des données
• Un troisième playbook ppedbdump.yml ,qui récupère une sauvegarde de la base de données depuis le serveur de production et qui l'envoie sur le serveur de test. Ainsi, la sauvegarde de la base données est présente sur les deux serveurs.
• La veille du projet, une panne technique est survenu sur le serveur contenant nos serveurs virtuels, et nous avons dû recréer rapidement une machine virtuelle Proxmox et réinstaller les serveurs grâce à nos playbooks. Ceci nous a permis de présenter le projet en se connectant au serveur de production

• Mise en place d'un VPN

• Objectif : Chiffrer les logs des serveurs renvoyés sur la machine syslog afin qu'ils ne circulent plus en clair
• Eviter le piratage et la récupération des informations de logs
• Il sera supervisé par Nagios afin de s'assurer de son fonctionnement

• Mise en place d'un outil de gestion de parc

• Objectif : Gérer le matériel informatique et réunir toutes les informations le concernant afin de pouvoir prendre des décisions le concernant (remplacement,...)
• Logiciel utilisé : GLPI
• Installation de GLPI et du plugin FusionInventory permettant de faire un inventaire automatique du matériel, grâce àun playbook
• Test d'inventaire avec FusionInventory sur un client Linux et un client Windows en l'installant sur ceux-ci
• Mise à la disposition d'un dossier partagé contenant le logiciel client d'inventaire FusionInventory
• Fichier goss permettant de vérifier la configuration du serveur GLPI

• Mise en place d'un serveur SAN

• Objectif : Permettre d'héberger de nouvelles données nécessaires au serveur stockant les bases de données, car celui-ci n'a pas la capacité stockage suffisante pour les stocker localement.
• Utilisation du SAN AOE, alternative à FiberChannel beaucoup moins chère et plus simple à configurer, qui suffit pour l'organisation SDIS29
• Vérification que la partition est exportée et que la machine de sauvegarde y a accès
• Les sauvegardes de la base de donnée seront également copiéees sur la partition SAN
• Configuration du SAN pour que les partations soient montées sur le seveur de sauvegarde au démarrage

Captures d'écran du projet

Activités du référentiel mises en oeuvre

D 1.1 Analyse de la demande
A 1.1.1 : Analyse du cahier des charges
A 1.1.2 : Etude de l’impact de l’intégration d’un service sur le système informatique
A 1.1.3 : Étude des exigences liées à la qualité attendue d’un service
D1.2 Choix d’une solution
A1.2.1 : Élaboration et présentation d’un dossier de choix technique
A1.2.4 : Détermination des tests nécessaires à la validation d’un service
A 1.3.4 : Déploiement d’un service
D 1.3 Mise en production d’un service
A 1.3.1 : Test d’intégration et d’acceptation d’un service
A 1.3.3 : Accompagnement de la mise en place d’un nouveau service
D 1.4 Travail en mode projet
A 1.4.1 : Participation à un projet
A 1.4.2 : Evaluation des indicateurs de suivi d’un projet et justifications des écarts
A 1.4.3 : Gestion des ressources
D.2.1 Exploitation d’un service
A2.1.2 : Évaluation et maintien de la qualité d’un service
D3.3 Administration et supervision d’une infrastructure
A3.3.1 : Administration sur site ou à distance des éléments d’un réseau, de serveurs, de services et d’équipements terminaux
A3.3.2 : Planification des sauvegardes et gestion des restaurations
A3.3.3 : Gestion des identités et des habilitations
A3.3.4 : Automatisation des tâches d'administration
D 5.1 Gestion des configurations
A 5.1.1 Mise en place d’une gestion de configuration

Fermer le projet

PPE 4

ONF

Contexte

l’Office National des Forêts est une association qui s’occupe du traitement des arbres, de l’accueil du public et de la production de bois.

Situation actuelle

Une base de données répertoriant les arbres est déjà en place, mais les bûcherons doivent signer un formulaire quand ils doivent la mettre à jour.

Besoins

Mettre en place une infrastructure permettant d’héberger deux applications :

• une application web, destinée aux forestiers, qui pourront planifier le travail des bûcherons, générer des statistiques liées au traitement des arbres et connaître les traitements que ces derniers ont subi.
• une application mobile qui permettra aux bûcherons d’identifier rapidement un arbre grâce à une puce intégrée dans celui-ci et d’en modifier les informations.

Ces deux applications ont pour objectif de faire gagner du temps au personnel.

Solutions mises en place

• Installation du serveur

• Installation d’un serveur web : Ayant travaillé presque exclusivement avec Apache, j’ai choisi Nginx afin d’obtenir des compétences sur les deux serveurs web les plus utilisés
• Installation d’une base de données : Utilisation de MariaDB avec lequel j’ai l’habitude de travailler. Il permettra de stocker la base de données qui contient les arbres
• Installation d’un dokuwiki permettant de recenser les modes opératoires suivis pour mener à bien ce projet.

• Gestionnaire de domaine Active Directory




• GLPI et FusionInventory

Inventaire d’un poste-exemple et déploiement d’application (qui n’a pas fonctionné) sur celui-ci. Liaison à l’AD afin que chaque utilisateur de ce dernier puisse utiliser son compte également sur GLPI. Cela évite à l’administrateur le fastidieux travail de recréation manuelle des comptes.

• Sécurisation de l’accès au serveur

Utilisation de HTTPS pour sécuriser les accès à l’application web et au dokuwiki. La base de données contient des informations personnelles sur les salariés qui doivent être correctement protégées par l’administrateur réseau

Captures d'écran du projet

Cliquer sur les images pour les agrandir

Application web


Liste des arbres et leur traitement

Graphiques de réparition des arbres selon différentes catérgories

Détails affichés lorsque l'on clique sur un arbre
Précédent Suivant

Application mobile


Page d'accueil de l'application

Liste des arbres

Détails affichés lorsque l'on clique sur un arbre
Précédent Suivant

Activités du référentiel mises en oeuvre

D 1.1 Analyse de la demande
A 1.1.1 : Analyse du cahier des charges
A 1.1.2 : Etude de l’impact de l’intégration d’un service sur le système informatique
A 1.1.3 : Étude des exigences liées à la qualité attendue d’un service
D1.2 Choix d’une solution
A1.2.4 : Détermination des tests nécessaires à la validation d’un service
D 1.3 Mise en production d’un service
A 1.3.1 : Test d’intégration et d’acceptation d’un service
A 1.3.3 : Accompagnement de la mise en place d’un nouveau service
A 1.3.4 : Déploiement d'un service
D 1.4 Travail en mode projet
A 1.4.1 : Participation à un projet
A 1.4.2 : Evaluation des indicateurs de suivi d’un projet et justifications des écarts
A 1.4.3 : Gestion des ressources
D3.3 Administration et supervision d’une infrastructure
A3.3.1 : Administration sur site ou à distance des éléments d’un réseau, de serveurs, de services et d’équipements terminaux
A3.3.3 : Gestion des identités et des habilitations
D 5.1 Gestion des configurations
A 5.1.1 Mise en place d’une gestion de configuration

Documents officiels des épreuves E4 et E6
Merci de cliquer sur les images pour accèder aux documents



E4 - Situation 1
Mise en place d'un VPN

E4 - Situation 2
Sécurisation d'un serveur web (HTTPS, pare-feu)

E6 - Tableau des compétences
Retour
Développement d'une map Minecraft
Description
Metamiles City est une map Minecraft conçue autour d'une ville urbaine comprenant de nombreuses infrastuctures telles qu'un port, un CHU, une gare, un périphériques, des lignes de bus et de train...
Captures d'écran

Gare ferroviere

CHU

Garage

Boulevard de l'Europe

Périphérique

Palais de Justice

Cinéma

Salle de cinéma

Signalisation

Immeuble
Précédent Suivant
Téléchargement
• V.1.0 07/07/2018
Retour